Applies to: R3 4.6c (which means it probably applies to all of 4.6)
If you’ve ever needed to build something outside of SAP that uses the SAP’s account set, profit center set, or functional area set hierarchies, it can be a big task. Ideally, you could use some sort of BAPI or remote hook into SAP and use its functions…unfortunately for me, that’s beyond my security priviledges. So, I was forced to rebuild what SAP does with its hierarchy. Here’s a jump start on the tables that SAP uses so you can use its structure.
Access the tables through SE16:
- SETNODE – contains any node that functions as a Parent node, and its subsets
- SETLEAF – contains value ranges for all sets…some sets will not show here because they only have subsets and no values as immediate children
- SETHEADERT – contains the set names…need to do a join to get the set names linked in.
These tables cover Account Sets, Profit Center Sets, and Functional Area Sets…among other things. You can distinguish between these types of sets in the SET CLASS field, for the most part. Here are the biggies:
- Set class: 0000 – Account Sets. You’ll also need to have some pattern in the SET ID or another field to filter out Account Sets. We preface all our account sets with ACCT-, so we can specify ACCT-* in the SET ID field and just get account sets.
- Set class: 0106 – Profit Center Sets. No need to filter SET ID unless you want to.
- SET class: 0000 – Functional Area Sets. Same set class as account sets above, so you’ll need some filtering mechanism. We preface all functional area sets with FUNCT-. Makes filtering easy.
I have used this structure to build a budget system in VB with a central SQL Server backend, with 30-40 concurrent users. It works well, but I’m not sure how to make the recursive nature of the algorithm super fast, so I created a table called SETCOMB (not found in SAP) that included all the sets, with each of their children.
It takes about 20 minutes to build all of my hierarchies, so I wish I had done some versioning of SETCOMB so I could build the table without having to make sure nobody was using it. Once the data was built, you would set the new version to be the production version.
The other thing I did was implement a caching system where once a hierarchy node was retrieved from the database, it would be written into either a text file or a disconnected recordset on the client’s machine. So any time you needed to call up a node, the first thing the system would do is to check to see if the text file existed. If so, it would use the text file, if not retrieve the data from your DB and write it out to client before passing to your function. This makes navigating through your hierarchy lightning fast.