topic Re: Secondary table in Application Development and Automation Discussions

Secondary table

Former Member — Thu, 17 Sep 2009 09:48:48 GMT

Hi All,

As i know there are secondary table for BSEG, like BSID, BSIK, BSAD and BSID.

But may i know is there such secondary table for table VBAK and VBAP ?

Please comment.

Re: Secondary table

Former Member — Thu, 17 Sep 2009 09:54:12 GMT

Not really, sales documents don't have the same statuses as accounting documents, such as open, cleared etc. There are other tables which link to VBAK and VBAP:

VBRK & VBRP - Billing documents

VEDA - Contract data (dates etc)

VBEH & VBEP - Schedule data

VBFA - document flow

VBKD - business data

VBPA - partners

VBUK & VBUP - status data

Hope that helps.

Re: Secondary table

Former Member — Thu, 17 Sep 2009 09:56:23 GMT

Hi,

BSEG is a cluster tables so you may say that BSID and all are its secondary tables (transparent tables), but VBAK and VBAP are themselves transparent tables, so they will naot be viewed in this fashion. VBAK and VBAP are similar to the BSID and BSAD tables.

Regards,

Sachin

Re: Secondary table

Former Member — Thu, 17 Sep 2009 09:59:14 GMT

No, the reason what I think might be is that BSEG is a cluster table and thus cannot have any indices on it nor it can be joined with other table. Hence there are secondary tables which serve as index tables for faster access of accounting data.

But VBAK and VBAP are normal transparent tables which can have indices and there is no requirement for additional secondary tables.

BR,

Advait

Re: Secondary table

christine_evans — Thu, 17 Sep 2009 10:01:50 GMT


> Hi All,
> 
> As i know there are secondary table for BSEG, like BSID, BSIK, BSAD and BSID.
> But may i know is there such secondary table for table VBAK and VBAP ?
> 
> Please comment.

The secondary FI line items tables only exist because BSEG is a cluster table and so you can't add extra indexes to it. In an ideal SAP FI world (in my opinion anyway), BSEG would be a transparent table with indexes set up so that it could be used to do everything that the secondary tables are currently used for. Which would get rid of the wasteful denormalisation of data that results from having multiple tables holding the same data.