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.