When there is no other way, or how to use the BSEG table

Well, well....

I am writing this post while one of the programs I am coding, the one related to the BSEG table executes.

And the post is related with this program, because I said before that the BSEG table should be avoided, but there are times, like this when there is no other option.... OR the other option (if there is one) is too complicated to implement and.... you are just too lazy to do it on time because you have no time left to waste there.

Anyway, the thing is, reading the Performance and Tuning forum on SDN I found that there is a general consensus that using the for all entries (i.e. selecting info from the DB, based on already existing info of an internal table) is bad bad bad!. I didn't know that, and I used the for all entries for almost everything... but now, running a simple select of a big table, with a for all entries... it is the same as enjoying the summer in hell.

This is the dreadful select:


select bukrs
belnr
gjahr
buzei
[...]
into corresponding fields of table it_bseg
from bseg
up to n rows
for all entries in git_bkpf
where bukrs = git_bkpg-bukrs and
belnr = git_bkpf-belnr and
gjahr = git_bkpf-gjahr and
buzei in rg_dummy_buzei.


That had awful results. The idea was that with the up to n rows line, the thing would improve a lot (n was 1000 at first, so it was a very small quantity of rows to select)... but to be honest, the thing broke just like the others, if not worse.

I then realized the central idea of this post: if you need to use the BSEG table, then do not use joins (because you can't! hahaha) and never use for all entries, because they are one of the roots of evil. Use a very minimalistic select and try to give the whole key to the compiler, even if it has empty ranges on it:


select bukrs
belnr
gjahr
buzei
[...]
into corresponding fields of table it_bseg
from bseg
up to n rows
where bukrs in s_bukrs and
belnr > cursor_belnr and
gjahr in rg_dummy_gjahr and
buzei in rg_dummy_buzei.


Sorry for the quality of the code text... I will try to use CSS for this... when I learn how to use CSS ;)

BSEG Table: Just avoid it

The BSEG Table, the "Accounting document segment" is a cluster table that, as far as I understand, stores all the information for almost every financial movement on the SAP system. As you can maybe guess, this can be (and IS) a huge table, and there is a lot of information there that, to be read takes HUGE amount of time. Because of this, programmers (and users) do not like to read (or use programs that read from) the BSEG table directly. As a cluster table, this is not a real DB table, but a somehow "logical" table and you can use the real DB tables that make this big monster, instead.

The structure for this is:

BKPF: Is the Accounting document header, therefore, the hub that links all the others...

And all the others are:
I (Open Items):
BSIK [K (Vendors)]
BSID [D (Customers)]
BSIS [S (G/L Accounts)]

A (Cleared Items)
BSAK [K (Vendors)]
BSAD [D (Customers)]
BSAS [S (G/L Accounts)]

This shows how all table relate to each other and how the name scheme works. It becomes much clearer now!

Another tip I just read: The key for the BSEG table is built from the BUKRS, BELNR, GJAHR and BUZEI fields. If you can get the first three fields, the fourth can be used in the select even if you don't have it. Just create an empty RANGES for that field and in the WHERE clause, use something like 'BUZEI IN EMPTY_RANGE' to give the whole key to the compiler.