Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member181923
Active Participant

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:

 

http://forums.sdn.sap.com/click.jspa?searchID=72663652&messageID=10384788

15 Comments