MATERIAL LEDGER - PARTE 3 - ANÁLISIS DE PRECIO DE MATERIAL

En esta entrada veremos cómo interpretar la información que se muestra en la CKM3N, unas nociones sobre cómo se distribuyen las diferencias de precio cuando se tiene ML y cómo se calcula el precio interno periódico durante el cierre.

Como se ha mencionado y visto anteriormente, la CKM3N es la transacción de análisis de precio de material; un informe donde, en diferentes categorías, vamos a tener registrados todos los movimientos de un material para un periodo concreto.

Altas  

En la carpeta de Altas, dependiendo de las fuentes de aprovisionamiento del material, podremos tener diferentes subcarpetas o subcategorías como Fabricación, si el material se fabrica in-house, o Pedido si se compra, etc.

Independientemente de la fuente de aprovisionamiento, y lo que es también válido para el resto de categorías, lo que vamos a tener en el informe en cada una de sus columnas es el detalle, para cada operación que ha generado un documente de material ledger, de:

• La cantidad de producto involucrada en el alta, las unidades, KG o T, etc. de producto que se ha dado de alta mediante una EM por orden de fabricación o por pedido de compras por ejemplo.

• La Valoración Provisional de esa alta en base a la valoración a precio estándar; la EM siempre la vamos a tener valorada a estándar para los materiales que se tendrán en cuenta por ML en el cierre.

• Las Diferencias de Precio y/o por Tipo de Cambio que puede haberse dado en los flujos de alta: durante la EM/RF,  durante la liquidación de órdenes de fabricación,...

• El Precio unitario de la Cantidad Base teniendo en cuenta las diferencias de precio si las hubiera para la operación concreta. 

Con esto, el sistema agrupa (suma) en cada subcarpeta y carpeta los totales para cada columna, de forma que se llega a un "precio para fabricación", un "precio para Altas", usándose la fórmula:

(valoración provisional + diferencias precio + diferencias TC) / Cantidad.

Así, viendo el caso de la imagen de arriba, para Fabricación tendremos:

Valor real Fabricación = Valor prov + diferencias = (2.911.668,25 - 177.843,13) = 2.733.825,12

Precio Fabricación = Valor real / Cantidad = 2.733.825,12 / 12.678,780 = 215.622,10 para las 1000 T de Cantidad Base.

Algunos comentarios:

• En las EM por órdenes de fabricación, el producto entra a su valoración a precio estándar y no se dan diferencias de precio, por eso la valoración provisional coincide con la real.

• En fabricación, cuando se liquidan órdenes de fabricación, el saldo que se liquida siempre son diferencias de precio (saldo por la diferencia entre los costes imputados a la orden y que la cargan y la EM que abona la orden)

• Si tenemos pedidos, podría darse que, si el pedido es por un valor diferente al que se está valorando (a estándar) el material, en la EM tengamos diferencias, como en el ejemplo de abajo:

Inventario Acumulado 

En la línea de Inventario Acumulado lo que vamos a tener son los datos de Inventario Inicial y los de Altas acumulados, es decir, la suma de la cantidad de producto a inventario inicial y de la cantidad dada de alta durante el periodo, y la misma suma para la valoración inicial, y las diferencias de precio:

de tal forma que para el inventario acumulado también tendremos una valoración real y un precio para la cantidad base que se calcula en las mismas condiciones que antes, pero para los datos acumulados. En nuestro ejemplo de arriba:

Inventario acumulado = Inv. inicial + Altas mes

Val.prov acumulada = Val prov. de inventario inicial + Val. Prov. mes

Diferencias = Diferencias que se arrastran del inventario inicial + Diferencias del mes

Precio a Inventario acumulado = (3.550.781,22 - 220.153,94)/15.461,780 = 215.410,34

Este precio del inventario acumulado no tiene porqué coincidir con el precio de altas o el de inventario inicial, porque para el stock de cada una de estas categorías, se tiene una diferencia de precio.

Este precio a inventario acumulado, aunque durante el mes podrá ir actualizándose, el que se obtiene a cierre será nuestro PIP o precio interno periódico con el que se podrá revaluar el stock y los consumos del periodo.

Este PIP es distinto al que podemos ir viendo durante el mes como precio del inventario acumulado porque sólo es a cierre cuando el sistema, ejecutando el cockpit de ML  (la CKMLCP), determina e imputa las diferencias de precio de los niveles inferiores a los niveles superiores de manera proporcional a los consumos que se hayan realizado

Consumos

Dependiendo del uso del material y de su propia naturaleza, este se podrá consumir en la fabricación de productos semi-terminados o terminados en niveles de fabricación subsiguientes, se puede haber vendido mediante pedido de cliente, etc.

Así, en Consumos tendremos también diferentes subcarpetas que se corresponderán con la actividad que minora el stock del material: 

Así, si el material se consume para fabricar un semi-terminado, en la carpeta de Consumos, Fabricación, veremos las cantidades consumidas para tal fin. Del mismo modo, si el material se vende, veremos los datos de las unidades vendidas en la carpeta de Pedido Cliente.

Con respecto a los importes que se muestran en Consumos, la lógica que se sigue difiere un poco a la de la carpeta de Altas. 

Durante el periodo todos los consumos se valoran provisionalmente a su precio de valoración a estándar, como en el caso de las altas. Pero en Consumos no tenemos diferencias de precio hasta que en el proceso de cierre se van asignando las diferencias de precio del inventario acumulado de forma proporcional a lo que se ha consumido. 

Por lo que durante el mes, val.prov = valor real y el precio que vemos en la columna Precio para la carpeta de consumos (y subcarpetas) es justo el precio estándar.

Llegado el cierre las diferencias de precio se distribuyen entre el stock final y los consumos que se han realizado para fabricar en niveles superiores, por lo que en esta carpeta vamos a ver ya diferencias y un precio calculado que diferirá del estándar y una valoración real diferente  a la provisional

Así por ejemplo, si tenemos unas diferencias acumuladas de 31.769,27€ para un stock acumulado de 20.124.883,612 Litros, a una cantidad de 3.087.303 litros consumidos en fabricación, le corresponderán unas diferencias de 

3087303*31.769,27/20.124.883,612 = 4.873,63€

que es lo que vemos en diferencias de precio de consumos en fabricación.

Esta diferencia de precio que se lleva a los consumos en fabricación, se usará en el cálculo del precio real del siguiente nivel, esto es, si para fabricar el componente A consumimos B y en la fabricación de B tenemos diferencias, esas diferencias se asignan a A de forma proporcional a lo consumido, de tal forma que el precio que se calcule de A por el material ledger las tendrá en cuenta. 

Inventario Final

En la carpeta de Inventario Final vamos a tener la diferencia de las cantidades y resumen de valoraciones a estándar y precio real del stock total, el acumulado descontando los consumos.

En la imagen de arriba podemos decir que tenemos un stock final del periodo de 12.005.852,612 Litros, que valorados a un estándar (de 488,41€) nos da un valor de stock de 5.863.778,49€.

Pero a cierre se ha determinado un PIP de 489,99€, por lo que la valoración real del stock es de 5.882.731,00:

Este valor de stock a precio real se puede actualizar si realizamos la revaluación del stock con material ledger.

MATERIAL LEDGER - PARTE 2 - CONTROL DE PRECIOS CON CO-PC-ACT

En la entrada anterior vimos una aproximación a las funcionalidades básicas del Cálculo del Coste Real / Material Ledger, sobre todo desde la perspectiva del Control de Precios y la problemática de las distintas valoraciones de los materiales.

Como vimos, con el cálculo del coste real, todos los movimientos de materiales se valoran de forma preliminar a precio estándar. En el ledger de materiales se registran todas las diferencias de precio y de tipo de cambio, y en base a éstas se calcula a cierre de periodo el precio interno periódico, que se puede utilizar para:  

• Revaluar el stock de fin de periodo.
• Revaluar consumos y trabajo en curso.
• Actualizar el precio estándar para el siguiente periodo.

En esta entrada veremos qué opciones nos da el sistema para valorar los materiales cuando usamos el cálculo del coste real.

Cuando activamos el cálculo del coste real, la relevancia del control de precio de un material depende del indicador Determinación de Precios del maestro de materiales.

Podemos tener una determinación de precios 2 y valorar el material con un control de precios a estándar o variable, o podemos tener una determinación de precios 3 y valorar el material a estándar, calculándose a cierre el precio interno periódico.

Con la opción de la determinación de precios 2, el cálculo del coste no va a calcular un PIP (PUP - periodic unit price en inglés) a cierre de periodo, pero tendremos la ventaja, si usamos monedas paralelas, de tener valorado el material en múltiples monedas, ya sea a precio estándar o PMP.

Con la opción de la terminación de precios 3, sólo podremos usar el control de precios S y durante el cierre de material ledger se determinará el PIP o precio real del periodo teniendo en cuenta las desviaciones de precio.

Son estos materiales con control/determinación de precios S/3 los que considerará el cockpit de cierre de ML (la transacción CKMLCP), durante la tarea de selección de materiales a valorar.

Resumiendo, los requisitos que deberemos cumplir para obtener el coste real del producto, son:

• Material Ledger activo
• Cálculo del Coste Real activo
• Control de precios del material "S"
• Determinación de precios del material "3"

Veamos a continuación unos ejemplos que ilustrarán las diferencias que tendremos para materiales con una determinación de precios u otra. Las veremos en la transacción de análisis de precios de material, CKM3N o, equivalentemente, navegando desde el botón correspondiente desde la pestaña de Contabilidad 1 del maestro de materiales.

Determinación/Control de precios 3/S

Cuando tenemos la determinación de precios 3, como hemos visto, sólo tenemos la opción de valorar los materiales a precio estándar (control de precios S).

En este caso, durante el periodo, todas las altas y consumos del material se van a realizar al precio estándar constante de 100:

de tal forma que nuestras 20 unidades de alta se valoran a 2.000 y se consumen 10 a 1.000.

Las diferencias de precio se registran en cuentas de diferencias de precio y se van grabando en el ledger de materiales para poder calcular el precio real a cierre de periodo.

Durante la ejecución de la CKMLCP, el cockpit de material ledger, el sistema sólo tomará en cuenta los materiales con determinación de precios 3 del ejemplo anterior:

Se obvían los materiales con determinación de precios 2, tanto a control de precios S como a V.

Teniendo en cuenta las diferencias de precio, se obtiene un valor real de las altas y del inventario acumulado (altas más inventario inicial si hubiera) y el sistema calcula el precio real, precio con el que se podrá revaluar el stock y los consumos.

Como vemos en la imagen de arriba, tenemos tanto en Consumos como en Inventario final, un precio distinto al original de 100 unidades monetarias.


Determinación/Control de precios 2/S

Con determinación de precios 2 y control de precios S, nuestras altas y consumos se seguirán valorando al precio estándar constante de 100.

La diferencia aquí la tendremos en el cierre de ML. 

Aquí vemos, que aunque se ha determinado un precio de altas, ni los consumos ni el inventario final se valora al precio calculado. 

Como peculariedad, mencionar que, al igual que en el caso de materiales con determinación de precios 3, se generará también para éstos un documento de ledger de materiales en el flujo de documentos financieros:

Determinación/Control de precios 2/V

Por último, con determinación de precios 2 y control de precios V, en el entorno de documentos financieros también vamos a tener documento de ledger de materiales

pero en el análisis de precio del material podemos ver que la valoración de las altas, consumos, etc. coincide con la valoración real. No vemos diferencias de precio, pero podrían darse en infracobertura de stock. 

Aquí ML no es quien determina el precio real a cierre de periodo, en cada movimiento de entrada, se ajusta el precio de valoración del material (el precio variable), y los consumos se valoran al precio de cada momento, justo de como se haría sin ML activo.

OPENSAP - NUEVOS CURSOS

OpenSAP anunció esta mañana en su cuenta de Twiter la disponibilidad de nuevos cursos para el primer trimestre de 2015.

Lanzan una nueva versión de actualizada sobre SAP RDS, las soluciones paquetizadas en base a las Best Practices de cada sector, que ya se impartió en Mayo 2014 y que permitía acceder a la cualificación necesaria para que los partners crearan sus propias services offerings certificadas aprovechando las soluciones innovadoras (Mobility, HANA, CRM, Cloud...) y el contenido de las distintas RDS´s.

En esta nueva edición encontramos un nuevo topic, el Big Data, además de más contenido relacionado HANA, o User Experience, entre otros temas.

También vemos una nueva edición del curso Introductión to SAP HANA Cloud Platform y del curso BI 4 Platform Innovation and Implementation, que seguro que interesará a los consultores técnicos que se estén introduciendo en el mundo de HANA o de los servicios en la nube, o a los administradores de SAP BusinessObjects BI 4.


Hay que recordar que todos estos cursos son totalmente gratuitos y son impartidos en video por expertos de SAP de diversos ámbitos. Para participar sólo tienes que registrarte y enrolarte en el curso, o, si el curso ya ha concluido, siempre se puede tener acceso a los vídeos y presentaciones que se siguen; no así a las tareas o exámenes enfocados a evaluar el seguimento del curso de cara a obtener un certificado de aprovechamiento expedido por OpenSAP.

Para más información, visita su página.

MATERIAL LEDGER - PARTE 1 - FUNCIONALIDAD - CONTROL DE PRECIOS

Comienzo con esta entrada una serie de publicaciones centradas en las funcionalidades que ofrece el cálculo del coste real / material ledger. 

En este primer post trataré la problemática de la valoración de materiales a la que el cálculo del coste real intenta dar solución.

-----------------------

Es sabido que las funcionalidades básicas que aporta COPC-ACT/ML son:

1. Poder valorar el stock en monedas paralelas
2. Permitir el cálculo del precio real del producto

La primera funcionalidad hace referencia a la posibilidad de gestionar los precios de los materiales en hasta tres monedas, de forma que se pueda tener valorado el stock de acuerdo a la valoración del grupo, la valoración legal local de la Cía., o de acuerdo a la valoración de centros de beneficio.

Esto no es sólo útil en entornos corporativos multinacionales donde se precise valorar el stock en la moneda local y en la moneda del Grupo. En países con mucha inflación les da la posibilidad de tener valorado el stock en una moneda fuerte.

La segunda funcionalidad básica lo que permite es el cálculo del coste real, pero, ¿acaso las empresas no conocen cuál es el coste real de sus productos, cuánto les cuesta su producción? 

Lo cierto es que sí conocen o tendrían una idea del intervalo de valores en el que se pueden mover sus costes de producción, al fin y al cabo esto va a determinar el saber si el precio de venta al que venden el producto terminado les aporta un beneficios cuando se antepone el precio de venta a los costes de ventas (costes de producción más otros costes como administrativos, comerciales,...). Lo que ocurre es que el precio de valoración del producto puede no estar reflejando fielmente todos los costes en los que se incurren durante el proceso productivo. Pero, ¿cómo es esto posible? 

Para responder a esta pregunta, abordemos las alternativas que tenemos a la hora de valorar los materiales

Valoración a Estándar o Precio Medio Variable

En SAP es el Control de Precios en el maestro de materiales es el que determina cómo se valorarán el material, a precio estándar (S) o a precio medio variable (V).  

SAP recomienda que los productos terminados o semi-terminados, los fabricados in-house se valoren a estándar, mientras que los que se aprovisionan externamente se valoren a PMP.

Dependiendo de el control de precios fijado, el reflejo contable será uno u otro cuando se den diferencias de precio.


Control de precios S

A control de precios S, todos los movimientos de stock se valoran al precio estándar  constante

Las entradas de mercancías a almacén siempre nos va a hacer el movimiento habitual de existencias contra variación de existencias 

y cuando afloran diferencias de precio vamos a tener movimientos contra la cuenta de diferencias de precio.

Pero, ¿de dónde pueden venir estas diferencias de precio?

• Si tenemos un material de fabricación propia valorado a 100 €/UN y los costes que se han incurrido en su fabricación (imputados a órdenes de fabricación por ejemplo), son mayores o menores, esta desviación se traduce en una diferencia de precio.

• Si el material se ha comprado, en el momento de contabilizar la EM el material se valora a su precio de valoración estándar de por ejemplo 100 €/UN, si se está comprando más caro, esto se traduce en una diferencia de precio.

Con esta valoración, vemos, las desviaciones son transparentes. El precio estándar es la referencia contra la que comparar las desviaciones, pero si estamos hablando de un material que se compra y su precio de compra fluctúa constantemente, es evidente que su valoración no es realista.

Si lo que estamos hablando es de materiales fabricados el problema puede ser más grave si tenemos fabricación en varios niveles,  porque podemos tener desviaciones en un primer nivel de producción, un nivel intermedio del semi-terminado o en el último nivel del terminado. El producto final lo estaremos valorando a 100€/UN, pero podemos estar teniendo desviaciones en cada uno de los niveles de producción.

Ejemplo

en este ejemplo tenemos valorado el terminado a 100 en base a la valoración de sus componentes (sub-niveles), pero tanto en el último nivel como en los inferiores, surgen desviaciones que no están siendo reflejadas en el precio del producto terminado.

Control de precios V

A valoración a PMP, tanto en fabricación propia como en aprovisionamiento externo, las desviaciones que se puedan dar se traducen en la actualización del precio del material.

Por ejemplo, la cuenta de existencias se contabiliza con el valor de la EM, que será el precio del pedido. Si el precio del pedido es diferente al PMV del material, en el momento de contabilizar la entrada, se actualiza el precio medio variable.

Si a su vez, el precio en factura es diferente al de pedido, cuando se contabiliza la factura, el sistema corrige el valor en el registro maestro de materiales, de manera que se modifica el precio medio variable.

Con esto, en todo momento tenemos el precio y el valor del stock actualizado, pero si el stock de un material es inferior a la cantidad especificada en la factura debido a que se han retirado materiales entre la entrada de materiales y la recepción de factura, sólo se cargará o se abonará el stock real en la cuenta de existencias. El importe pendiente se contabilizará en una cuenta de diferencias de precio. Tenemos infra-cobertura de stock
Ejemplo:

1. Stock 100 UN a PMP 1,2€/UN. Valor stock 120€

2. EM 100 UN a precio pedido 1,30€/UN

3. Tendremos un stock de 200 UN con un valor de 120 + 130 = 250 PMP = 250/200 = 1,25 €/UN

4. Se consumen 170 UN valoradas al PMP de 1,25 €/UN. Tendremos un Stock de 30 UN y un valor de stock de 30 * 1,25 = 37,5 €.

5. Ahora entra la factura por un importe de 1,5 €/UN en lugar de los 1,3 del pedido. El pedido era de 100 UN pero sólo nos quedan 30 UN en stock. 

La modificación del valor del stock se calcula en base al stock restante:

• 30 ( 1,5 - 1,3 ) = 30 * 0,2 = 6. 

El stock es de 30 unidades valoradas a 43,5 €. El PMP será de 43,5/30 = 1,45 €/UN. El resto de diferencias se contabilizan en cuentas de diferencias de precio:

• 70 ( 1,5 - 1,3 ) = 70 *0.2 = 14 €

es decir, los 20€ de diferencia que hay entre el pedido y la factura se distribuyen de esa forma entre el valor del stock y las diferencias de precio.

Esto puede conducir a precios de valoración irreales, ya que, como vemos, el precio con el que se valora una salida de material depende del momento de la contabilización de la salida. Si el consumo del ejemplo anterior fuera posterior a la factura, se hubiera tenido otra situación.

Cálculo del Coste Real

Las valoraciones a estándar o variable, como vemos, tienen sus ventajas e inconvenientes.

Resumidamente, podemos decir:

Y con la funcionalidad del cálculo del coste real , lo que ofrece el sistema es intentar aunar las ventajas de ambas valoraciones. ¿Cómo se consigue esto?

Valorando los materiales estándar durante todo el periodo.
Calculando su precio real o precio interno periódico a cierre de periodo.

De esta forma conservamos las ventajas de valorar nuestros terminados o semi-terminados a un precio fijo que nos sirva de referencia para el cálculo de desviaciones, pero a cierre de periodo tenemos en cuenta todas las diferencias de precio que se han dado para calcular un precio real con el que valorar nuestro stock final del periodo, e incluso post-valorar nuestros consumos.

Al periodo siguiente nuestros materiales siguen valorados a estándar, siendo este estándar, bien el que ya se tenía previamente, o uno actualizado con el precio real calculado por ML.

En sucesivas entradas iremos viendo cómo se calcula el precio interno periódico por ML y algunos puntos de interés al respecto.

SHUTDOWN & REBOOT

Después de varios años sin publicar en mi blog sobre SAP y ABAP, recuperaré varias entradas, aún válidas hoy día, e intentaré no dejar de mantenerlo actualizado con publicaciones de interés práctico en el ámbito de la consultoría SAP Finanzas y Controlling.

Sería interesante que fuera también un punto de intercambio de opiniones y/o experiencias en el mismo ámbito

Espero no defraudar a los visitantes

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)