VERSIONES PLAN : tipos de cambio y copia de versiones

En este post voy a comentar una incidencia real resuelta con la funcionalidad estándar de copia de versiones plan-plan para centros de coste.

El caso se inicia cuando el key user de controlling se da cuenta que los informes de datos plan de centros de coste están devolviendo unos importes en EUR que corresponden a un tipo de cambio incorrecto con respecto al USD;  el tipo de cambio p (Conversión estándar para planificación de costes) que usa la versión plan 1 para la conversión entre la moneda de la Sociedad CO y la moneda de la transacción no se actualizó a su debido tiempo.

En la versión 1 se sube a SAP el presupuesto en dólares para ciertos centros de coste (moneda de la transacción y del objeto dólar), y al no haberse actualizado el tipo de cambio a tiempo, toda la conversión de monedas USD-EUR se ha hecho con los últimos datos válidos, los de 2009.

El tipo de cambio se actualizó en la transacción S_BCE_68000174 después de subir los datos plan, cuando debería de haberse hecho antes,

con lo que al sacar los informes de centros de coste en EUR y en USD, el tipo de cambio que se aplica es de 1,20705 dolares por euro.

Guardando en la transacción RPC0 los parámetros de usuario para monedas de informes, bien en moneda de la Sociedad CO (EUR), bien en moneda de la transacción (USD)

El informe S_ALR_87013611 (Centros de coste:  Real/Plan/Desviación) mostrará que para datos plan en versión 1 en euro y en usd:

Es decir, 30.798,92 USD / 25.515,85 EUR = 1,20705

¿Cómo solucionar esto? Con la transacción KP97, copia de datos plan en plan. En el menú en Finanzas -> Controlling -> Contabilidad de centros de coste ->  Planificación -> Ayudas planificación -> Copiar.

Tendremos que seguir los siguientes pasos:

1. Parametrizaremos otra versión, llamémosla Z como copia de la versión 1 (o cualquier otra versión plan objeto de incidencia), asegurándonos que usa el mismo tipo de cambio.

2. Si no está actualizado el tipo de cambio, actualizarlo en la  S_BCE_68000174 (se trata de una operación financiera, por lo que se tendría que tratar con el usuario responsable correspondiente.

3. Hacer una copia de los datos plan de la versión 1 a la versión Z con la opción Monedas Plan igual Moneda de la transacción:

Esto es importante, ya que si los datos a copiar se han registrado con moneda de la transacción igual a USD, nuestro objetivo es que en la nueva versión se copien con el mismo importe en USD, sólo debe cambiar el importe en EUR.

Siguiendo este procedimiento, si originalmente teníamos 1.000 dólares y 0,82847 euros en la versión 1,, deberemos de tener 1.000 dólares  y 0,68292 euros en la versión Z.

Y realmente ocurre así tras la copia. Si vamos a la tabla COSS y comparamos los registros para el centro de coste en la versión 1 y la versión Z, veremos que en los campos de moneda de la transacción y de moneda del objeto (la moneda del objeto también es dólar) los importes no cambian, pero en los de moneda de la Sociedad CO sí.

Pero nuestro objetivo final no es tener los datos plan en una nueva versión. Nuestro objetivo es corregir los datos de la versión 1, la versión en la que se suben los datos operativos del presupuesto, por lo que nos falta un último paso: Hacer la copia inversa.

Después de comprobar que todos los datos se han copiado correctamente y que los informes para datos plan de centros de coste devuelven el importe en dólares sin variación y que en euros aplica el tipo de cambio que queremos:

es decir, 30.798,92 USD / 21.033,18 EUR = 1,46430, podemos proceder, con la KP97 de nuevo, a hacer la copia de la versión Z a la versión 1. Tendremos ya solucionado el problema.

Este mismo procedimiento aplica también para los datos plan de proyectos/elementos pep mediante el uso de la transacción correspondiente del menú de Sistemas de Proyectos, CJ9B o CJ9BS, o para los datos plan de órdenes con la KO14.

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)