SAP FI - Curiosidades de la tabla BSEG

La tabla BSEG al igual que la transacción SPRO, son el pan de cada día para muchos consultores SAP, haciéndolas en muchas ocasiones que sea imposible que pasen desapercibidas.

El origen de la tabla BSEG se remonta a las primeras versiones de SAP, lo que se refleja en el diseño de la misma, aunque considerando que en las décadas de los 70 y 80, en las cuales el principal foco de las estrategias de diseño se encontraban en el rendimiento y optimización de los recursos de hardware.
SAP decide entonces orientar su desarrollo hasta una arquitectura universal de sistemas operativos y bases de datos, por lo que se hacia necesario implementar una capa de abstracción que sirviese de interprete entre las funciones de alto nivel y los diferentes entornos de ejecución.

¿Pero y donde entra la tabla BSEG?

Justamente considerando la decisión de soportar varias bases de datos, tales como: Oracle, MSSQL, SAPdb, Sybase, Informix, DB2, etc. Se tiene como resultado encontrar restricciones de diseño en todos lados, relacionadas especialmente con funcionalidades que no son estándar, esto es que solo unos cuantos RDBMS hacen y otros no.La tabla BSEG sirve esencialmente a un propósito funcional muy importante, esto es permitir la persistencia de los documentos de contabilidad, conteniendo todos los datos necesarios para las integraciones con los módulos de CO, MM, FI-AA, SD, etc. Es por esto que se plantea  que la tabla deberá contener muchos campos, lo que se traduce en un conflicto con la capa de abstracción, frente a lo que se presenta una pequeña "solución", esto es diseñar la tabla BSEG como un cluster, es decir, la estructura de la tabla lógica es diferente de la tabla física en la base de datos.BSEG: Tabla Cluster,
RFBLG: Tabla POOL.

Tabla RFBLG

Então os dados da Tabela BSEG é armazenada em formato RAW, ou seja, concatenam-se todos os bytes de dados de cada campo em uma só "linguiça" e fatia-se em tamanhos de 3800 bytes.

Por isto não se acostuma-se utilizar "select's" na tabela BSEG, pois se é necessário filtrar por um simples campo de conta contábil, o SAP irá solicitar todos os registros do banco e verificar para cada registro a equivalência de bytes posicionais de cada registro com a conta contábil.

Só é permitido o uso através do uso de leitura da tabela pela sua chave primária.

La nota 1892354 permite transformar la tabla BSEG desde una tabla cluster a una tabla.

 

De tal manera que desde este punto  se genera una nueva lista de programas, integraciones, Jobs, exits, etcs... que no requerirán acceder a las tablas auxiliares BSIS, BSAS, BSAD, BSID, BSAK, BSIK.

 

1)  En la tabla BSEG para todas las bases de daros el tamaño de registro corresponde a un registro de la tabla  RFBLG, por lo que no necesita leer dos o más registros para conformar un registro de la tabla BSEG.

 

2) La transferencia de datos entre RFBLG y BSEG se realiza directamente en el direccionamiento de memoria, no existe la necesidad de conversión.

 

3) Debido a la existencia de tablas de índice, la mayor parte del tratamiento de los datos de lectura y la actualización se lleva a cabo a través de estas tablas y la tabla BSEG no se consulta.

 

4) La ganancia en el procesamiento de inserción en la base de datos es insignificante y distribuido en toda transacción comercial. Debido a esto, probablemente se presentan los retrasos en la actualización de la BSEG.

 

Para aplicaciones, transacciones, informes de código de cliente, se abre toda una nueva gama de aplicaciones.

1) Permite realizar consultas en la tabla BSEG haciendo uso de campos diferentes a la clave primaria.

2) Permite la creación de índices para optimizar las consultas.

3) Permite la creación de vistas Trasparentes con otras tablas.

4) Permite el uso de la tabla BSEG haciendo uso de Queries para atender soluciones puntuales e inmediatas.

 

Versión original del artículo

Máximo número de líneas alcanzado

The message F5727 (Maximum number of items in FI reached) when trying to post an invoice on a purchase order via MIRO is because there is a limit of (999) line items which can be posted per FI document.      

                                                                         

This is because the line item number (BSEG-BUZEI) field  length is defined as (3) numeric positions, i.e., (999) line items. 

                                                                              

The most commonly used workarounds are as follows:    

                         

1)  Implement FI summarization (per note 36353 ).                                                                               

2)  Cancel the original billing document and split it into smaller  documents using different payment terms but actually with the  same terms, in case of invoice verification.   

                                                                            

This will avoid the (999) line item limit for FI postings. Please also have a look at the note 117708 Not to be able to create more than 999 FI line items is a basic restriction. The line items field on the BSEG table (BSEG-BUZEI) is a 3 position numeric field. To change this to a field greater than 3 positions will not be possible.This restriction is being addressed but because BSEG is a cluster table and involves many programs  this will take some time to change.(note 36353).                                                                         

      

This is the answer from the point of view of the support, the mentioned note provides a workaround.If you would like,  according  to your own needs, you may change the field length, however  please consider that  this is deemed a modification to the standard  and this is  not                

supported by the primary support.

        

Please have a look again at note 36353. This note mentions fields which often prevent summarization for reference type 'MKPF' and which can be put into table TTYPV for reference type 'MKPF':                                                                         

      

table name     field name                                                             

BSEG           BPMNG                                                                  

BSEG           BPRME                                                                  

BSEG           ERFME                                                                  

BSEG           ERFMG                                                                  

BSEG           MATNR                                                                  

BSEG           MEINS                                                                  

BSEG           MENGE                                                                  

BSEG           PAOBJNR                                                                

BSEG           POSN2                                                                  

BSEG           WERKS                                                                  

BSEG           BWTAR                                                                               

 

You should add these fields in transaction OBCY. But please take into account that Using FI-summarization will to a certain extent cause a loss of 'traceability' in your system. You will no longer have a one-to-one relationship between the postings in MM and FI.                     

 

A single posting in FI may reflect a number of line items in a MM document, so a drill down will not always be as effective as before.                  

 

Several drawback to using summarization are listed in note 36353 (I cannot judge if these will cause you problems) it depends on your configuration in OBCY and your business procedures.                                                                               

Please review the related notes, I have attached for your reference, the only other option you have if you do not use these notes is to  split the original invoice in several parts so that the FI document  has less than 999 lines.