Skip to Content

OK, so here’s the scenario.


Your client has a big bunch of bills and payments that need to be cleared, and since they all involve advance payments from customers, some of the clearings will be net zero, some will result in CR memos (pymnts > bill), and some will result in debit memos (bill > pymnts.)


So the spec comes across your desk because you’re the local FI/FM/CO “expert” (meaning that relatively speaking, you’re really an ignoramus because there are no real experts in F-32 internals anymore – they’re all retired or gone to their reward in “occurs 0” heaven.)


So of course the first thing you do is Google “SAP F-32 BAPI” and you find that over the past five or ten years, many folks in your position have searched for the elusive “F-32 BAPI” to no avail – it can’t be found. And worse still, even though there are some out there who claim that you can use BAPI_ACC_DOCUMENT_POST to do clearings, no one’s backed up this claim with a WIKI or a code snippet or a blog or anything you can use.


So, you say to yourself, well, I guess I’m gonna have to bite the bullet and write a BDC.


But then, fortunately, your professional pride and common-sense kicks in and you say to yourself something like the following.


Hold on a minute there, Self. This is 2011, remember? It’s the age of SOA, the age of background modular services that are decoupled from SAP transactions so that they’re more easily consumed by WebDynpro’s, etc. So is it really appropriate in this day and age to admit that in order to write an F-32 WebDynpro, you’d have to call a BDC?


Which, if you think about it, is the same as saying, that in this day and age, you’ve got to use a lowly “screen-scraper” to emulate F-32. (Because that’s all a BDC is, if you think about it … it’s a “screen-scraper” before-the-fact, rather than a “screen-scraper” after-the fact.)


And so you say to yourself … Self, we can’t sink that low. We can’t admit that in 2011, we’re gonna have to use a “screen-scraper” to clear some lousy bills and payments.


So you talk to you dev manager and you tell him or her that if he or she will not insist on you writing a BDC right-off, you’ll spend a little of your own time seeing if a “pseudo-BAPI” can be built, so the deadline can be met either way.


And sure enough, with some good test cases, and a little patience, and a lot of time in the debugger, you find that it’s a very straightforward matter to create a “pseudo-BAPI” for F-32 that will do all three types of clearings mentioned above.


Confidentiality clauses prevent me from providing any specific code, but I can tell you the basic “trick” to use here, and you can fill in the blanks on your own.


First, pick the “pymnt > bill” test case that you’ve created and run it thru F-32, being sure to turn on the debugger via “/h” before you hit your final SAVE (this is the SAVE that you hit after SAP prompts you for the extra comment text for the residual.)


When you hit the debugger, you’ll see that SAP fires off subroutine FCODE_BEARBEITING in SAPMF05A, and that this subroutine cycles several times before it finally settles down and starts doing the real work that has to be done for an ok-code of “BU” (= SAVE.)


At this point, create a spreadsheet with a lot of tabs and document EXACTLY what SAP has put in these structures and itabs:


xbkpf, xbseg, xbset, xbseu, xbsegz, xaccit_ext, xausz1, xausz2, xausz3, xausz4, xbkp1, xbsec, xbsed, xbseu, rsgtab, renum, clrtab, bkdf, rf05a, saltab, bsez, and postab.


(A lot of these will be empty unless your clearing case involves certain additional complexities involving things like compression, etc etc.)


Next, step thru FCODE_BEARBEITUNG in the debugger and at each branch-point, decide if your client and your situation requires or doesn’t require the code that SAP executes. (If SAP calls a subroutine or a form, assume you’ll need it even if you don’t really think you do, because you don’t know what SAP may be doing inside the subroutine or form regarding setting of parameters, exports to memory, etc.)


Once you have this documentation in your spreadsheet and once you’ve documented what you need from FCODE_BEARBEITUNG, create a function group and make sure that in its TOP, you include SAP’s TOP from SAPMF05A. Then, of course, create a copy of SAP’s subroutine FCODE_BEARBEITUNG and add it your function group. Then, finally, write a wrapper function module in which you: 1) sets up all the above structures and itabs just like they are in your spreadsheet; and 2) call your copy of FCODE_BEARBEITUNG. (This “wrapper” module basically sets up all the above itabs and structures from a pair of BSID records that you pass to it – in this case the BSID records for the bill and advance payment that you want to clear.)


Believe it or not, you’re done.


Call your wrapper function and catch the number of the main clearing document that SAP generates.


Then do an SE16n on BSID and BSAD – you’ll see that your BSID records have moved to BSAD with clearing dates.


Then do an FB03 on the clearing document, and in Document Environment, you’ll see that all the usual secondary accounting documents have been correctly generated by your “pseduo-BAPI” for F-32.


Now repeat the”discovery” process above for your “bill > pymt” case and net-zero case, so you know how to set up your itabs and structures for these two cases. Also, make sure to step thru the debugger in each of these cases, just to make see if SAP is doing anything inside FCODE_BEARBEITUNG for these two cases that’s different from what it did in the “pymt > bill” case.


And … voila … you’re done.


Yes yes yes … I know all the objections to this approach that people may raise.


And in response, I give two answers that will cover all of them:


First, if SAP isn’t seriously embarassed that in 2011, one of its key financial processes:


1) has not been rewritten in ABAP OO


2) is still declaring all of its critical itabs “occurs 0” (with headers)


then believe me … you can take it to the bank that at this point, SAP is never ever going to change FCODE_BEARBEITUNG in a way that will make your copy of it fail.  (SAP’s problem here is the same as IBM’s old “370/BAL” problem that I’ve mentioned here at SDN before.)


Second, remember that you’re not trying to write an all-purpose pseudo-BAPI for every SAP client in the world, and every configuration contingency. You just have to write one for your client with its configuration, and that’s why the “discovery” process mentioned above will work just fine. Sure, you may need a little maintenance now and then, but what doesn’t need a little maintenance now and then?


In closing, I want to thank Rob Burbank (an ABAP General forum moderator, among many other things), who gently suggested that I was going to have to use more of FCODE_BEARBEITUNG than I originally thought. You can see our discussion by following links from this latest link in ABAP General:

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

    1. David Halitsky
      The problem is not just in the “clearing” itself, i.e. the generation of a clearing document and the movement of bsid records to bsad.  As you can see from the links I provided to my discussion with Rob in ABAP general, there are a number of functions which will do this basic “clearing”.

      As my functional pointed out, the other part of the problem lies in the generation of the secondary accounting records that you’ll see in FB03 (“Document Environment” menu selection after you clear thru F-32.

      And juding from the four different FI_DOCUMENT_PROCESS calls in MF05A FCODE_BEARBEITUNG (three BEFORE SAP’s call to POST_DOCUMENT and one AFTER SAP’s call to POST_DOCUMENAT), a “pseudo-BAPI” for clearing will not generate the usual secondary accounting documents generated by F-32 unless it includes AT LEAST these calls from FCODE_BEARBEITUNG.

      Also, note the calls to the old BTE’s in this subroutine, as well as the validation and substitution calls.  I have not checked to be certain, but I am willing to assume here that Rob Burbank is correct in his assertion that we’ll break something in SAP if we don’t include these BTE calls and substitution calls and validation calls in our “pseudo-BAPI”.

  1. Mark Chalfen
    Hi David,

    Great blog and a favourite topic of mine.

    I have come up with a number of solutions.

    In the US – Lockbox is a popular tool to allocate cash against invoices and credits, and create debit notes.

    Payment Advices are also widely used. There are IDOC’s available to create PA’s.

    Lastly and my favourite due to its flexibility, is creating a program to put a code (say the payment document number) in all of the documents that are being cleared – so put the value in  say in XREF1. If you have 2000 lines in your remittance, you will have 2001 lines with the same value in XREF1, with the sum of the lines coming back to zero, so they can be clear (matched) via F.13. You can also create debit notes prior to the clearing, making sure the credit line has the value in XREF1.

    1. David Halitsky
      for the plethora of different ways to slice and dice the problem.

      Again, I’m curious about the same question I asked Eric and Paul – do the alternatives you mention generate the correct set of secondary accounting documents, as well as moving the docs to BSAD?

        1. David Halitsky
          … the ones you see in FB03 “Document Environment”.  Which of your solutions generate those ?
          1. Mark Chalfen
            HI David,

            They all move the BSID values to BSAD.

            The other thing to look at is the “payment usage”

            This shows you all the items cleared via a clearing document.

            1. David Halitsky
              … but there seems to be some reason why you don’t want to answer the question, so I’ll just let the FB03 matter drop.  It’s very important to this client and the prime’s functionals here, but this may not be the case at all clients.  Thanks again for sharing your deep knowledge of this subject with us.


              1. David Halitsky
                … and here is the resolution of the F-32/FB03 question.

                If you do an F-32 WITH a credit or debit residual (for example, payment greater than bill), then after F-32 has cleared the pymnt and bill, SAP will associate the controlling and special purpose documents with the CLEARING document, and you will see these secondary documents in FB03 when you bring up the clearing document and then bring up the “Document Environment” pop-up.

                So, since the client/functional at this site wants the “pseudo-BAPI” to emulate the F-32 process “WITH residuals”, the “pseudo-BAPI” must include not just the FCODE_BEARBEITUNG call to POST_DOCUMENT (which does the actual clearing”, it must also include FCODE_BEARBEITUNG’s four calls to FI_DOCUMENT_PROCESS (three before the call to POST_DOCUMENT and one after.)

                But as Marc has pointed out to me off-line, you can generate your residual items “up-front” and then clear afterwards, in which case the controlling and special purpose documents will be associated with the RESIDUAL item, not the clearing document.

                1. David Halitsky
                  Hi Marc – I just wanted to close the loop on the actual reason why F-32 is generating secondary acctg documents as well as a clearing doc at this site.  It’s not the question of whether residuals are generated or not, which is what I previously thought.  Rather, I believe it’s the case that F-32 will generate secondary acctg documents if and only if entries for things like profit center, fund, fund center, etc. were made on the 1st and 2nd payment screen when the payment was originally booked.  Since that’s the use-case this client wants and needs, that’s why the functional was so insistent that the F-32 “pseudo-BAPI” also generate the secondary docs the same way that F-32 does.  But I think that if a client does payments without the fancy frills data entry, then F-32 will not have the info required to generate secondary docs, so after clearing via F-32, no secondary docs will show in FB03 “Document Environment” when the clearing doc is brought up in FB03.
  2. Andrea Olivieri
    Hi David,
    I agree with your feelings because I faced with the same problem 4 years ago in Release 4.7, and there, the good “old” batch input saved my life.

    Today, after 4 years and 1 release upgrade, the same batch-input is still running without any issue.


    1. David Halitsky
      Hi Andrea – you’ve precisely illustrated the problem for the SAP community.  The good news (in the “tribal” sense, to use MPratt’s term) is that you’ve got a solution that’s working for you and your client, even after four years.

      The bad news (in a more “global” sense) is that you’re happy with the solution.

      Because so long as the SAP customer base stays happu with BDCs/BatchInput’s, SAP will have no incentive whatsoever to finally start providing alternatives that arise from doing the kind of decoupling of functionality from transactions that SAP is supposed to be doing in the first place (in order to bring about THE SOA RAPTURE as soon as possible.)


  3. Paul Hardy
    I never liked F-32 much, as you have said it is an old fashioned dinosuaur of a thing which is never going to change, so I wrote my own version. I used function POSTING_INTERFACE_CLEARING to actually clear the open items in the same way that FB05 does. I think F-32 calls FB05 in some way to clear open items.
    1. David Halitsky
      no … F-32 definitely does not call FB05 in any size/shape or form.  In addition to POST_DOCUMENT, it calls FI_DOCUMENT_PROCESS four different time in four different modes, and it’s these calls that are doing the actual clearing AND the associated secondary accounting documents that you see in DB03 (Document Environment from the menu) after you run F-32 and generate a clearing document.

      Which leads me to the same question that I asked Eric earlier in this thread – when you use FB05 instead of F-32, do you see the secondary accounting documents in FB03 afterwards?  Also, can you clear with residuals in FB04 the way you can in F-32. 

      The requirement at this client was to clear with residuals as well as “even-steven” – that’s why F-32 was selected as the model.


Leave a Reply