A. Overview of the Clearing Process
An accounting entry on the asset & liability side often needs to be “reconciled” with a business partner (e.g. customer, vendor, bank etc.). Pending the reconciliation, these items need revaluation, regrouping or reclasssification in line with various disclosure and reporting requirements.
This “reconciliation” process in SAP is implemented using a “Clearing Transaction”. Some examples of clearing are (i) Clearing of a customer invoice against incoming payment (ii) Clearing of a Vendor Invoice against outgoing payment (iii) Liquidation of Outoing Payment entries (Cheques Issued but not presented) against Debits received from bank in a bank statement. As a result of “Clearing”, the accounting entries change from “Open” to “Cleared” items.
B. Limitations/ Probelms in clearing using standard transactions
1. A clearing transaction cannot be “Parked” or held, unlike other accounting transactions (such as Incoming Invoice).
2. A clearing transaction is screen based (i.e. you have to create a batch by providing the screen number and fields). Unfortunately, the screens are dynamically selected based on inputs on the previous screen. Besides, Screens elements are liable to be changed in version upgrade (e.g. Field KNKK-KUNDE of screen 0210/SAPMF02C in ERP 6.0 changed to RF02L-KUNDE in ERP 6.04). Report RFBIBL00 makes the process a bit easier, but has a some more limitation.
Therefore, it is extremely difficult to design a robust clearing process with an external interface (B2B processes or external workflow applications).
C. A Glimmer of hope (FM AC_CLR_FB05_ADAPTER)
I found a Function Module “AC_CLR_FB05_ADAPTER” which does not call any transaction, does not depend on screen elements but still does the clearing.
However, the “Reference Transaction” (BKPF-AWTYP) is hardcoded as REACI ( Real estate document). Therefore, reversal of such documents will be done using BKPF-AWKEY (EXTERNAL document reference). But AWKEY is also hardcode to time (SY-DATUM+SY-UZEIT). Therefore, you will end up reversing all documents posted within that second – a potentially dangerous side effect in large installation.
Next problem is that the reference field of the accounting document header (BKPF-XBLNR) is not captured. If this field is defined as mandatory in the document types configuration, then you can’t post the document.
D. Looking under the hood
If you look at the coding of this FM, you will find that it is just a wrapper for the following 4 FMs:
1. AC_CLR_DOCUMENT_CREATE (Called after data transformation)
3. FI_DOCUMENT_NUMBER_INTERNAL (to get hold of the documents posted)
4. BAPI_TRANSACTION_COMMIT (As usual)
Copy FM AC_CLR_FB05_ADAPTER to your own name space, comment out extraneous code, check/ resolve the use of global variables and are ready to go. But a couple of road blocks. Read on.
E. The good part
Though the FM AC_CLR_FB05_ADAPTOR sets some Global variables before calling the FM AC_CLR_DOCUMENT_CREATE (both share the same Function Group); these are reset and reinitialised in FM AC_CLR_DOCUMENT_CREATE. Therefore, we can happily do away with the first FM without worrying for any side-effect.
Another good thing is that the Exits for Validations, Substitutions & BTEs are still called. Therefore your business logic will not be bypassed.
You can use AWTYP = ‘BKPF’ so that the normal reversal transaction (FB08) work and use the existing logic of sy-datum+sy-uzeit in BKPF-AWKEY. If you prefer to identify these documents separately, then make up your own transaction type (SAY ZZZZZ) and maintain in table TTYP. This can be used as Custom AWTYP.
Then generate an unique key for BKPF-AWKEY and pass it to AC_DOCUMENT_POST in parameters i_awref (first 10 chars of the key) and i_aworg (last 10 chars of the key).
You should also get the Accounting document number before update (just to make sure that the document has passed all the existing business logic without errors) by using FM FI_DOCUMENT_NUMBER_INTERNAL. You need to pass AWTYP (ZZZZ), AWREF (first 10 char of key) and AWORG (Last 10 character of key) as fields of table parameter t_accdn. The FM will return by filling the fields BUKRS, BELNR & GJAHR of this table parameter. DO NOT FORGET to export x_get_all = ‘X’ – otherwise you may not get return values. Also remeber that t_accdn may return with multiple records in case of Cross-Company-Code postings.
F. The Catch (in FM AC_CLR_DOCUMENT_CREATE)
1. You have to pass a line in the table parameter t_accit. Even when there are no residual items (i.e. the debits and credits of the items being cleared are matched), you still have to send a record with Zero Amount.
2. For each line in record in table parameter t_accit, you have to send 2 records in table parameter t_acccr. One with document currency (i.e. CURTP = ’00’) and another in local currency (i.e. CURTP = ’10’). (I would love to hear from community members why is it so).
3. The FM creates new line(s) to represent the contra-entries for the documents being cleared. Unfortunately, the Reference Field (BKPF-XBLNR) is not populated in these newly created items. If XBLNR is not mandatory, you may get away by not using the field at all. But then you loose the use of a very important indexed field. In case XBLNR is mandatory, you will have to use an Implicit Enhance ment.
G. Implicit Enhancement to FM AC_CLR_DOCUMENT_CREATE
There are no explicit enhancements available in the FM. But, as per the enhancement framework, an implicit enhancement is always available at the end of any FM. Use this enhancement to copy the XBLNR value from the first line (accit-posnr = ‘0000000001’) to the remaining lines.
A smaple code for the enhancement is shown below:
*$*$-Start: (1)———– -$*$*
ENHANCEMENT 1 YF_ENH_CLEARING_OPEN_ITEMS. “active version
Data : l_xblnr like bkpf-xblnr.
LOOP at t_accit where xblnr is not INITIAL.
l_xblnr = t_accit-xblnr.
IF l_xblnr is NOT INITIAL.
LOOP AT t_accit.
t_accit-xblnr = l_xblnr.
PS: No screen shots! How boring!! Sorry – could not work out how to transfer from ClipBoard to this screen.