Monday, October 26, 2009

Hidden BADIs

There is a very practical BADI in R3 for developing custom ATP scenarios, named ATP_PUBLISH_RESULTS. But one strange thing is this BADI does not show up in the SE18 queries, for example when doing a query for ATP*. So until recently I did not know about this BADI at all.



But it will show when inputting the full name.



So why is it hidden in SE18 queries? With some debugging it is easy to see that a F4 query in SE18 will go to table SXS_ATTR with ATP* as the pattern for the EXIT_NAME field and with INTERNAL different from X. It turns out that this INTERNAL field marks the BADI as internal (only to be used by SAP) so it becomes hidden from the F4 query in SE18.

So next question was: are there many internal BADIs? It turns out there are about 200 in APO and 400 in R3. So I suppose that it is well worth digging on this table if nothing can be found in the “external” BADIs and exits. Although one should avoid using the internal BADIs I suppose it makes a better option than standard code changes or some extreme hacks.

Labels: ,

Wednesday, September 23, 2009

OnSAP.com - questions and answers on SAP topics



I've been working on SAP for a long time. Of course there is still a lot to learn, but on the specific topics I specialize and focus most of my work on, after some time there is no book or SAP documentation with new knowledge. The best and maybe only way to continue learning is getting new challenges and finding solutions, and learning how other people solved hard problems.

Internet forums are great places to find good questions and answers. Unfortunately sometimes the forums have too much noise, bad questions and bad answers. One site that I think does the right thing is stackoverflow. Although it is a forum, it has some mechanisms to increase visibility of the best questions, give credit to the right answers and to the people that write the good questions and answers. The OnSAP website tries to be the same for SAP questions and answers.

It is a place where I will post my questions and hopefully my answers when I find them. It starts with a small community but at least on APO and ABAP there will be enough knowledgeable people to make it a good place to discuss hard topics. I also invite all of you to post your questions there, and give some answers if you feel like helping and improving the open knowledge (both the software and the contents of the site are open licensed).

Labels:

Thursday, July 16, 2009

Typical projects

Typical project of the 90's: FI, CO, SD, MM, PP, sales organizations, warehouses, distribution centers and maybe factories.

Typical project of this decade: trade company in Luxemburg, Switzerland or other low tax country; stocks owned by the trade company but physically in a different location; outsource production but control the planning of raw materials and possibly reorder from a central location; have the outsourcing partner stocks and in-process productions in the system as if it was a standard plant.

It's amazing the base model continues to be the same. But in the past it was clean and now it looks quite twisted.

Labels: ,

Saturday, April 25, 2009

And now? Going back to ABAP?

So Oracle buys Sun and gets Solaris, Mysql, MaxDB and Java. The first is a very important database but not very relevant to enterprise and SAP world (although it is used in SAP xMII). The second (previously named SAP DB) is the core to SAP APO LiveCache. And the last, the Java programming language, is the programming environment on which most new SAP products are developed and is also used for the cross platform GUI. And I would guess a lot of customers run on Solaris.

Before this purchase Oracle already had the most used database in SAP deployments. Is it me, or this is too much Oracle on SAP's backyard? If it was in my house, I would start doing some cleaning.

Labels:

Sunday, March 22, 2009

Marked Cell in Demand Planning Macros

I wanted to allow the users to choose a planning book cell, then click on a macro button to open a pop-up window with additional information related to the cell. But it does not seem to be possible to get the marked cell when developing planning book macros.

The standard macro functions PLOB_MARKED and COLUMN_MARKED work when selecting full rows and columns. Consider the following example macro:



It is possible to use that macro to identify a cell if the user selects both the row and column (pressing the control key to allow that kind of selection). But that is very user-unfriendly.



It turns out that most of the functionality for getting the marked cell in the macros is already available in the lower level macro functions. The standard function /SAPAPO/MARKED_ELEMENTS is used in the macro functions that return the marked row and column. That function also has information on the marked cell, so with some simple modifications it can be used for returning the selected cell.

It was easy to develop new functions to check the row (PLOB) for the marked cell and a function to check the column for the marked cell. Both call internally the modified /SAPAPO/MARKED_ELEMENTS and are based on the standard functions.

Then it is possible to develop macros that act on cells, to put the toolbar button for the macro and to open an ALV with cell detail information.



I still find it strange that marked cell macro is not available in the standard. Perhaps it is in some recent release. IMHO is a must have for planning books.

Labels: ,