AÑADIR CAMPOS A INFORMES DE PARTIDAS DE CO

Veremos en este post el método a seguir para añadir nuevas columnas a la estructura de línea del informe CJI3 de partidas individuales reales de proyectos y elementos pep.

Este método se basa en la nota explicativa: 325546 - CO line item reports: Creating a user-defined field, y con él podremos añadir nuevos campos, ya sean campos a medida, o simplemente campos estándar no disponibles, a los informes de partidas individuales de controlling, ya sean reales, plan o comprometido, y ya sean de cecos, órdenes, o proyectos.

Supongamos que queremos añadir a la CJI3 el campo Número de pedido  para el caso de partidas con origen en factura de ventas. Lo primero que debemos hacer es crear un proyecto en la transacción CMOD para asignarle la ampliación COOMEP01, pues esta ampliación contiene, entre otras, la exit  EXIT_SAPLKAEP_001, que permite añadir campos a los informes de PI´s reales (otros de los componentes hacen lo mismo para los informes para el Plan y para el Comprometido).

Una vez asignada la ampliación:

• Crearemos la estructura CI_RKPOS que deberá tener como campo el que deseamos añadir a la estructura de línea del informe, es decir, el campo Número de pedido, llamémoslo ZVBELN.
• Programaremos la exit mencionada para rellenar el nuevo campo.

En la exit tenemos la estructura cs_record que contiene cada una de las partidas que posteriormente se visualizan en el informe. Añadido el campo a la estructura ci_rkpos, también lo tendremos disponible en la estructura cs_record, por lo que lo podremos informar accediendo a tablas.

Tenemos el número de documento de referencia, que para partidas con origen en facturas de SD, será el número de la factura, en el campo  cs_record-refbn por lo que podremos ir a las tablas VBRK y VBRP (de facturas de sd) y de estas obtener el número de pedido del campo VBELN e informarlo en el campo correspondiente de la estructura, cs_record-zvbeln.

Adicionalmente:

• Deberíamos limitar la exit a los informes de proyectos con la sentencia check i_rep_object eq 'PD' al inicio de la exit. Así, no se ejecutará el resto del código para los informes de cecos, órdenes, etc.

• Como el campo que queremos rellenar lo tenemos sólo para las partidas con origen en facturas de SD, también deberíamos limitar el código principal de la exit a la operación de referencia VBRK, esto es, tendremos que añadir al inicio, la sentencia check cs_record-awtyp eq 'VBRK'.

Llegados a este punto ya tendríamos todo el desarrollo abap listo, lo único que nos faltaría sería realizar la parametrización necesaria para que el campo se muestre en el ALV de la CJI3. Esto lo hacemos parametrizando el cluster de vistas V_TKALV en la transacción SM34, donde indicamos una serie de especificaciones técnicas para la correcta visualización del nuevo campo. Estas son:

• Datos del catálogo de campos. Aquí añadimos el nuevo campo a la estructura KAEP_COAC además de algunas características de este.
• En dependencias de selección deberemos añadir los campos del informe que son necesarios leer para poder rellenar el nuevo campo. En nuestro caso el número de factura (número de doc. de referencia)

Con todo esto, ya tendríamos en el informe CJI3 una nueva columna con el dato del número de pedido.

REALINEACIÓN DE PARTIDAS DE COPA - KEND

Una funcionalidad un tanto desconocida pero interesante cuyas implicaciones deberíamos conocer, es la llamada realineación de datos en CO-PA mediante la transacción KEND, una vía con la que modificar los valores de características de Objetos PA.

¿Qué tiene de sigular la KEND? Pues que, como sabemos, una vez que en SAP se ha imputado a un objeto de imputación de CO, este no se puede modificar, con lo que esta transacción supone tener un mecanismo con el que saltarnos esta norma, al menos en PA.

Pero, ¿por qué querríamos modificar los valores de características de algunos Obj. PA? Pues porque quizás se han producido cambios en la lógica de derivación de características y quisieramos mantener los datos históticos en consistencia con los actuales, es decir, REALINEAR los datos existentes con las reglas de derivación actuales.

Otro motivo para usar la realineación podría ser la inclusión de una nueva característica al catálogo de campos de la Sociedad PA. En este caso, evidentemente, los datos históricos no la tendrían informada y con la KEND podríamos derivar este nuevo dato.

Una cosa que tenemos que tener en cuenta con esta funcionalidad es que, para mantener la integridad de los datos, la partida individual original no se modifica, lo que se modifica es el objeto PA. Para entender esto tengamos en cuenta:

• En la tabla CE4XXXX (donde XXXX es la Soc.PA) tenemos el Obj. PA. Es la tabla de segmento.
• En la tabla CE1XXXX tenemos las partidas individuales reales de PA.
• Por cada objeto PA, es decir por cada entrada en la CE4XXXX tendremos n entradas en la CE1XXXX, n partidas individuales.

así, al ejecutar la KEND para los datos seleccionados, en la tabla CE4XXXX modificaremos el valor de característica de la característica deseada, pero en la CE1XXXX las partidas asociadas no modificaran el valor de esa característica. Además, por cada Obj.PA modificado se creará una entrada en la tabla CE4XXXX_KENC, entrada que conservará los valores de características  primitivos.

¿Qué implica esto último? Pues que si ejecutamos un informe de Report Painter, al tratarse de un informe que totaliza por características que están definidas a nivel de Obj. PA, es decir, las características cuyo conjunto de valores definen cada Obj.PA (transacción KEQ3), los datos que mostrará serán los actuales. Pero si lo que ejecutamos es un informe de partidas individuales como la KE24, dependiendo de cómo se ejecute, mostrará las partidas tal como se contabilizaron o según la información actual del segmento:

Para ejecutar la KEND llevaremos a cabo los siguientes pasos: Crear la Ejecución, la cabecera, indicando su texto descriptivo y crear las órdenes de modificación deseadas:

En cada orden definiremos las condiciones de selección:

y las reglas de conversión: si queremos derivar de nuevo las características seleccionadas, o sobreescribirsus  valores:

Para terminar, mencionar que debemos tener en cuenta que en las condiciones de selección deberemos de usar características de nivel de objeto. Si tenemos las características A, B y C definidas a nivel de segmento y como condición de selección usamos los valores de característica A = 1, B = 2 y D = 4, donde D es una característica que no está definida a nivel de segmento, el sistema no encontrará en la CE4XXXX el valor 4 para la característica D, esta característica no se informa en la tabla de segmento. O usamos como condición de selección A y B o A, B y C.

Para más información:

Documentación de la HELP

Nota explicativa 94458 (precisa ususario de OSS)