MANAGEMENT ACCOUNTING

ESQUEMA: TFIN20_1
Estructura Organizativa
Cost Center Accounting: se usa para el controlling corporativo interno. Es un medio ideal con el que monitorear recargos (overhead) y asignarlos a las unidades organizativas que han incurrido en el coste. Product Cost Controlling: calcula los costes incurridos cuando se suministra un servicio o se fabrica un producto. Permite calcular el precio lmite mnimo al que comercializar un producto, siendo rentable. Profitability Analysis: Analiza el xito de la organizacin en sectores de mercado idividuales. Da una base con la que calcular precios, clientes objetivos, canales de venta,... Overhead Cost: Son aquellos que no pueden ser asignados directamente a la fabricacin de un producto o al suministro de un servicio. Se deben asignar todos los costes de estructura a los lugares o actividades en los que han surgido. Cost Center: reas separadas dentro de la controlling area en los que se incurren los costes. Cost Element: Describen el origen del coste, la naturaleza. Se definen como primarios (de origen externo) o secundarios (internos).(Clase de Costo) Activity type: define la clase de actividad que proporciona un centro de coste. Se usan para la facturacin de costes debidos a actividades internas. Internal orders: se usan para planificar, recoger y analizar los costes provenientes de actividades internas. ______________ La controlling area es la unidad organizativa dentro de una compaa en la que el cost controlling se lleva a cabo de forma completa y cerrada. No se pueden facturar costes que no pertenezcan a la misma controlling area. Se pueden hacer cambios de asignacin mientras no se hayan creado datos maestro o de transaccin. El control indicator se usa para activar o desactivar cierto componente de controlling para un ao fiscal. Asignacin 1:1 - Mismo plan de cuentas operacional - misma moneda

- La variante de ao fiscal puede tener diferentes nmero de periodos especiales, pero el mismo de posting periods. - Mismo periodo lmite. - Monedas: Mon. Soc.CO = Mon. SocFI , se puede definir una Mon.Obj para cada objeto. Mon.Tx. la moneda a la que se ha contabilizado. Asignacin 1:n - Mismo plan de cuentas operacional y posibilidad de plan de cuentas local por Soc.FI. - Mismo periodo lmite. - Pueden tener distintas monedas. - Monedas: Mon. Soc.CO puede diferir de las Mon.Soc.FI , la Mon.Obj = Mon Soc.FI. Mon.Tx. la moneda a la que se ha contabilizado. ______________

CCA - Master Data

Antes de crear centros de coste hay que definir la Jerarqua Estndar. Su nombre se define cuando se crea al Soc.CO. Todos los centros de coste deben estar asignados a ella. Estructura la compaa en unidades de toma de decisiones, control y responsabilidad con objeto de hacer el Overhead Cost Controlling. Los centros de coste que se crean o modifican en la jerarqua estndar tienen el estatus de inactivo. No hay problema en cambiar un ceco a otro nodo de la jerarqua. Se puede cambiar la asignacin de unidad organizativa, Soc.FI, Business area o cebe durante un ao fiscal solo si:

1 2 3

La moneda de la Soc.FI es la misma. Slo se han imputado costes plan. El ceco no est asignado a un activo fijo, centro de trabajo o maestro de personal.

El cost center category es un indicador que especifica la categora del ceco. Permite asignar las mismas caractersticas a similares cecos. Se puede usar para clculos, donde controla el porcenteje de recargo a aplicar a la cost center category. En customizing se puede definir lock indicators o valores permitidos para cada cost center category. Estos se propondran por defecto en el ceco. Las clases de coste primarias tienen su correspondencia en el Libro Mayor. Cuando se usan en un apunte requieren de un objeto de coste para identificar el origen del coste. Las clases de coste secundaras no tienen su correspondencia en el Libro Mayor, son de uso exclusivo de Controlling para identificar el flujo de los costes. Cuando se crea una clase de coste se debe asignar una cost element category. Esto determina para qu transacciones se puede usar la clase de coste Si un ceco proporciona una actividad a otro ceco, proceso,..., entonces significa que sus recursos estn siendo utilizados. Los costes de estos recursos necesitan ser facturados a los receptores de la actividad. El Activity Type sirve como factor de seguimiento para esta facturacin. La facturacin interna abona el emisor y carga el receptor usando clases de coste secundarias registradas en el dato maestro del Activity Type.

Se puede restringir el uso de una Activitdad para ciertos cecos, introduciendo la cost center category permitida en el maestro de la Actividad. Para permitir la facturacin interna de actividad, se necesita especificar qu ceco proporciona qu actividad a qu precio. Esto se hace planificando la Actividad/Tarifa. Statistical key figures: se usan como base para la facturacin. Puede ser el valor que representa el servicio suministrado por un ceco. Se pueden usar como base para operaciones periodicas como distribucin o subreparto y para analisis de valores estadsticos. Se definen como de valor fijo, como de valor total:

1 2

valor fijo (category 01). Permanece desde que se introduce hasta todos los periodos subsiguientes del ao fiscal. Solo se necesita introducir un nuevo valor si cambia. El total del ao fiscal es la media del total de los periodos. valor total (category 02). se imputan en el periodo en el que se registran. El total del ao fiscal es la suma de todos los periodos.

Se pueden guardar campos maestros para cecos, clases de coste y clase de actividad como dependientes del tiempo. Si se modifica alguno de esos campos, el sistema crea un nuevo registro maestro. Se especifica si un campo es dependiente del tiempo en Customizing. Ciertos datos del ceco, como asignacin a Soc.FI, Business Area o cebe son dependientes del tiempo y este tiempo no se puede reducir si se han hecho apuntes en el ao fiscal. La asignacin de un ceco a la Jerarqua Estndar no es dependiente del tiempo. Un cambio de asignacin reestructura el histrico y la informacin actual del ceco. Cuando se crean o modifican grupos, no se pueden crear variantes de seleccin. El rendimiento del sistema es mejor para grupos si no tienen variantes de seleccin. Los grupos no son dependientes del tiempo. La Jerarqua Estndar no debe contener sufijos. ______________

Event-Based Postings
Se necesitan intervalos de nmeros para todas las operaciones que generan documentos CO. Es posible copiarlos de otra Controlling Area. Hay dos pasos a seguir para asignar intervalos de nmeros: 1 Agrupar uno o ms business transactions juntas. 2 Asignar un intervalo a un grupo. Se definen los intervalos en CO independientemente del ao fiscal. Se recomiendan diferentes intervalos para plan y para real. Apuntes reales: se facturan o liquidan a otros objetos de coste. Uno y slo un apunte real ocurre en CO. Apuntes estadsticos slo tienen propsitos informativos, se pueden hacer tantos apuntes estadsticos como se desee.

El objeto de coste determina si el apunte es real o estadstico. Slo costes reales se pueden imputar a una orden real y slo estadsticos a una orden estadstica. A un ceco se pueden hacer apuntes reales y estadsticos. El sistema puede transferir el cebe como estadstico del maestro del ceco. Siempre se hacen apuntes estadsticos a un cebe. Slo se puede transferir un objeto real, por lo que si se tiene una orden real y un ceco, la orden pasar como real y el ceco como estadstico. Los ingresos slo se pueden imputar como reales a un objeto PA, pedido de ventas, proyecto u orden y estadstico a ceco o cebe. Se pueden especificar valores generales por defecto y especificos de usuario en los parmetros de seleccin de informes y la moneda del informe. Se pueden introducir como valores por defecto: datos bsicos (Soc.CO, ceco, grupo de cecos, clase de coste,....), parmetros para extractos, marco de tiempo para planificacin y reporting, moneda del informe, versin,... La variacin permite seleccionar un informe separado por cada elemento de un grupo. Slo se puede usar si se activa en la definicin del informe. Opciones de variacin: breakdown (todos los nodos), do not breakdown (el nodo ms alto) y Individual values. Default acc. assigment. El sistema toma el objeto de coste del maestro de la clase de coste (a nivel de SocCO y cuenta). Automatic account assigment. Customizing. El sistema determina el objeto de coste para el apunte primario segn lo parametrizado (ms detallado, a nivel de SocFI, Bu.Area o cebe) Tiene prioridad sobre la Default acc. assg. Se puede mejorar la exactitud de las imputaciones con validaciones y sustituciones. La validacin tiene ms fuerza y avisa con mensajes (I,W o E). La sustitucin no avisa Correction Posting: Traspaso manual de costes o de ingresos: No sender check Costes primarios traspasados bajo clase de coste original abono emisor, cargo receptor Traspaso de partidas individuales: Permite traspasar partidas especficas. Mantiene la referencia al doc. FI. Clase de coste original abono emisor cargo receptor.

Si tambin es necesario cambiar la imputacin en el doc. FI se tendra que revertir el doc.FI, pero slo si primero se revierte el traspaso si se ha hecho ya. Facturacin Directa de Actividad: Precisa de la creacin de Activity types (category 1 manual). Se precisa el ceco emisor y el receptor y la cantidad. Slo un ceco puede ser emisor. El receptor puede ser otro ceco, orden, proyecto,.... Se precisa planificar la tarifa de la actividad. El emisor es abonado y el receptor cargado bajo la clase de coste secundara de categora 43 (facturacin de actividad) que se toma del maestro de la Actividad. No se puede cambiar.

Period-End Closing
Periodificacin Para prevenir fluctuaciones en CO se deben distribuir los gastos irregulares a los periodos relevantes. Se puede usar el mtodo del porcentaje o del target=actual. Los costes devengados no tienen correspondencia con gastos en FI. Mtodo del porcentaje o recargo. El sistema carga el ceco con la cantidad de coste devengado y abono un accrual object definido por el usuario (ceco o internal order). Para la periodificacin es necesario crear clases de coste de periodificacin (category 3). Creamos la overhead (esquema de recargo) para la que necesitamos guardar: la base. sobre qu clase de coste se quiere aplicar el recargo sobrecargo. de cunto debe ser el porcentaje. credit. qu ceco u orden se quiere abonar (accrual object) y con qu clase de coste Se puede asignar el esquema a cualquier Soc.CO del Mandante. La asignacin tiene periodo de validez

Mtodo de terico = real. Se usa para periodificar costes tanto dependiente como independientes de actividad pero para los que el metodo de recargo no se puede aplicar porque no se puede encontrar la clase de coste para definir el recargo. Slo se necesita definir el objeto de abono (ceco u orden) y el periodo de validez de la clase de coste afectada. Se usa el tipo de clase de coste 4.

Traspaso peridico El emisor (ceco, orden, proceso ABC, pep u objeto de coste) recibe los costes primarios inicialmente y en el cierre se factura al receptor (ceco, pep, orden u objeto de coste). Se pueden restringir el nmero de receptores en customizing. Slo se puede traspasar costes primarios no se registran partidas individuales en el emisor. Si en el receptor Se puede revertir y repetir cuanto se quieran No se crea un registro de totales del abono en el emisor, se reducen los cargos Distribucin La distribucin factura costes primarios. Transfiere costes primarios desde el ceco emisor al objeto receptor. No necesita planificar actividades. El receptor puede ser un ceco, pep, orden, objeto de coste o proceso. Se pueden restringir los receptores en customizing. La distribucin mantiene la clase de coste original. Se puede revertir tanto como se requiera. El sistema escribe registros de totales para el abono al emisor (al contrario que en el traspaso periodico). El rendimiento es mejor en el traspaso peridico. La informacin en el lado receptor es la misma para distribucin y traspasos peridicos.

Subreparto El subreparto transfiere costes primarios y secundarios sumarizando las clases de coste en clases de coste se subreparto (category 42). El sistema escribe pocos resgistros de totales, por lo que el rendimiento es an mayor que en el traspaso periodico. Emisores posibles: ceco o proceso Receptores: ceco, orden, pep, proceso u objeto de coste. Las partidas individuales se registran tanto en el lado emisor como en el receptor. Se puede revertir. En el esquema de imputacin (allocation structure) se puede definir que clases de coste se liquidarn bajo qu clase de coste de subreparto. As no se necesita crear mas de un segmento. En el esquema se puede asignar clases de coste individuales, rangos o grupos a una clase de coste de subreparto. Ciclos Los ciclos se usan para definir los traspasos peridicos, distribucin y subreparto. Para mostrar la relacin entre emisores y receptores necesitamos: 1 desde qu objetos se facturarn costes. 2 a qu objetos se facturarn 3 qu costes se facturarn 4 sobre que base Un segmento toma los cecos emisores en los que los valores a facturar se determinan en base a idnticas reglas y los combina con objetos receptores en los que el tracing factor tambin se determinan por reglas idnticas. Cuando las reglas para un traspaso difiere, se debe definir otro segmento. Se deben crear ciclos separados para plan y real. Sender rule: Los valores emisores se pueden hacer bajo: 1 importes fijos 2 tarifas fijas 3 importe contabilizado El el lado del receptor se define si se guardarn: 1 Partes fijas 2 porcentajes fijos 3 importes fijos 4 partes variables Los ciclos dependientes usan el resultado del ciclo previo. Los ciclos independientes se pueden procesar en paralelo si tienen el mismo tipo de facturacin. Adems se tienen que asignar a diferentes cycle run groups. Slo se pueden ejecutar ciclos simultneamente en diferentes sesiones si pertenecen a diferentes grupos o si se procesan en fondo. La iteracin dentro de un ciclo es posible, entre ciclos no. La iteracin se repite hasta que se han abonado todos los emisores. Si se ejecuta un ciclo con el indicador de acumulacin activado, se imputarn los importes emisores contabilizados hasta el perodo actual mediante bases de referencia que se acumulan desde el perodo 1. Slo se recomienda si la relacin emisor-receptor es estable en el ao fiscal (el sistema lo chequea) Imputacin de costes manual (manual cost allocation)

Permite facturar costes primarios y secundarios manualmente. Escribe partidas individuales en el emisor. Se puede usar para todas las clases de coste excepto las de facturacin de actividad (43). Emisores y receptores incluyen cecos, ordenes, peps, procesos, grafos, actividades, pedidos, objetos de coste y objetos de RE. Slo imputan costes reales.

Internal Orders.
Real y estadstica: Cuando se crea un orden se define en el maestro si ser real o estadstica. Se usa ordenes reales para recoger costes e imputarlos mas tarde a diferentes receptores. Cuando se crea una orden se debe asignar a una Soc.FI . Si se usan balances por Business area, tambin se deben asinar a una business area. Se usan rdenes estadsticas para evaluar costes que no pueden ser itemizados en detalle en clases de coste o cecos. El ceco se puede guardar en el maestro de la orden. El sistema encontrar el ceco (real) del maestro de la orden, en otro caso habr que informarlo. Se tiene la opcin para rdenes estadsticas que guardar la Soc.FI y la b.area. Si se asignan, slo se podr imputar contra cecos que pertenezcan a la misma Soc.FI y business area. Para cross-company code o cross-business area controlling, no se debe asignar estos datos en la orden estadstica. No se pueden ni liquidar ni aplicar recargos sobre rdenes estadsticas. Datos maestros Se tiene que asignar cada orden a una clase de orden que le transfiere ciertos parmetros a la orden. La clase de orden define el propsito de la orden y la forma en la que la procesar el sistema. La clase de orden puede tambin usarse para agrupar juntas rdenes con caractersticas similares. La clase de orden es vlida para todo el Mandante, as se pueden usan en cualquier Soc.CO. La clase de orden tambin controla: 1 si la gestin de comprometida est activa 2 si contabilizaciones de ingresos se permiten 3 gestin de estatus 4 caractersticas de campos maestros (requeridos, opcionales,...) 5 Si el nmero de orden se asigna interna o externamente y el rango de nmeros 6 parametros para liquidacin, planificacin y presupuestacin 7 la presentacin de los datos maestros. En las imputaciones dentro de CO se crea, por lo general, un registro de totales propio por relacin de interlocutores (es decir, por combinacin emisor/receptor). En las rdenes se puede influir sobre esta actualizacin activando, activando parcialmente o desactivando el indicador de "Actualizacin de Interlocutor CO". Los datos maestros de la orden define los atributos incluyendo la asignacin organizativa: SocFI, BusArea, Centro, FunArea, cebe, pep,... En la clase de orden se asigna el layout del maestro de ordenes. El layout de pantalla se puede disear, si no se toma por defecto el layout standard. Los datos maestros se

muestran en hasta 5 pestaas que se pueden renombrar, y los campos se distribuyen en hasta nueve marcos. La gestin de estatus informa que fase particular en el ciclo de vida de la orden se ha alcanzado, y controla qu procesos estn permitidos. El estatus de sistema incluye cuatro estados: creada, liberada, completa tecnicamente y cerrada. Se pueden crear estatus de usuario para subdivisiones. El estatus de sistema y de usuario determinarn juntos qu transacciones son vlidas. El estatus puede permitir, advertir o prohibir una transaccion. Tambin se puede definir campos y autorizaciones dependientes de estatus. Se define el estatus de usuario y sus reglas asociadas en el esquema de estatus y se asigna a la clase de orden. El nmero de estatus asigna la secuencia para el estatus de usuario en el esquema de estatus. El esquema de estatus permite:

1 2 3 4 5

definir el estaus de usuario asignar la secuencia definir el estatus inicial definir qu estatus se establece en que transaccin permitir o prohibir transacciones.

Los grupos de rdenes son dependientes de mandante, por lo que slo puede usarse un nombre por vez incluso en distintas SocCO. Sin embargo, se pueden asignar rdenes de cualquier SocCO a un grupo. El rendimiento del sistema es mejor para grupos que no tienen variantes de seleccin.

Commitment Management
Un comprometido identifica costes que no se han incurrido an pero lo sern en el futuro. Se debe activar la gestin de comprometido tanto en la controlling area como en la clase de orden para crear informacin sobre comprometido. El estatus debe permitir la transaccin relevante. Se registra comprometido a una orden usando ciertas transaccines de MM y CO. Se registra autormaticamente cuando asignas una orden a un pedido de compras o solicitud de pedido. Se registra manualmente introduciendo funds commitment en CO. Se puede arrastrar el comprometido al primer periodo del siguiente ao fiscal en el cierre anual. Durante el arrastre de comprometido no se pueden procesar pedidos de compra del ao fiscal previo.

Period-End Closing
Recargo de gastos generales : Es el medio por el que se imputan costes a los objetos apropiados aplicando un porcentaje o cantidad fija. La base para el recargo son aquellas clases de coste primarias que se imputaron a la orden. Se pueden aplicar recargos tanto de plan como real o en base a comprometido. Las reglas para aplica el recargo se definen en el esquema del clculo del coste (overhead costing sheet) que combina tres elementos centrales:

base. que clases de coste a las que se aplicarn el recargo

2 3

recargo. permite definir la cantidad de recargo a aplicar (porcentual o basado en cantidad). Las dependencias permiten diferenciar por centro, socFI,... abono. define que objeto es abonado para balancear el cargo a la orden. Tambin se especifica la clase de coste

La clase de orden determina si el recargo es para plan, real o comprometido. Liquidacin Las rdenes de recargos se usan usualmente como colectores temporales de gasto. Concluida la tarea, los costes deben pasarse a sus destinatarios finales (ceco, pep, PA,..). Este proceso se llama liquidacin: 1 Externa. Cuando se liquida contra activo o cuenta de mayor. Actualiza FI. 2 Interna. Cuando liquida contra ceco, PA, PEP,... Se puede liquidar estadsticamente a un ceco, orden estadstica o pep estadstico adems de los receptores reales. La liquidacin no es obligatoria. Hay dos procedimientos para definir la liquidacin: 1 Bsica: permite liquidar el 100% de los costes a un ceco o cuenta de mayor bajo una clase de coste. Se introduce el dato en el campo Cierre de Periodo del maestro de la orden. 2 Extendida: Permite crear en el maestro la Norma de Liquidacin que: liquida a uno o ms receptores como peps, pedidos, PA,.. Especificar cul ser la regla de distribucin. En la liquidacin extendida, el proceso es controlado via asignacin en los parmetros de liquidacin del maestro de la orden. Estos parmetros incluyen el perfil de liquidacin, la esquema de imputacin, la PA transfer structure (esquema de cuenta de resultados). El perfil de liquidacin, que especifica los valores por defecto de los otros parmetros se especifica en la Clase de Orden. Los parmetros por defecto se pueden modificar en el maestro. El perfil de liquidacin se tiene que especificar en el maestro si se usa liquidacin bsica. Se especifica que receptores estn permitidos. El parmetro central que controla la liquidacin es el perfil de liquidacin: 1 determina si se requiere la liquidacin 2 especifica receptores vlidos y por defecto 3 establece indicadores de liquidacin 4 define parmetros de gestin de documentos 5 identifica otros valores por defecto como el esquema de imputacin, el esquema de cuenta de resultados y el esquema de orgenes. El esquema de imputacin controla que clase de coste origen se asigna a la clase de coste de liquidacin o bien si se usa la clase de coste original. Para usar el esquema de imputacin primero se crean los grupos de clases de coste (primarias y secundarias) usadas en los cargos a la orden. Despus en la IMG se vinculan los grupos de clases de coste a una asignacin de liquidacin. Por cada asignacin, estipulamos por tipo de receptor si se usar la clase de coste original o una de liquidacin. Se deberan usar clases de coste de liquidacin para reducir el volumen de datos y separar los costes imputados a la orden al receptor con una mayor descripcin. El esquema de cuenta de resultados controla la asignacin de clases de coste a campos valor en PA analtico. Se usa slo si se liquidan ordenes directamente a objetos PA. El esquema de orgenes controla la liquidacin a diferentes receptores dependientes de la clase de coste origen o grupo imputada a la orden usando diferentes normas de liquidacin. Para usarlo se asigna al perfil de liquidacin o se activa en el maestro de la orden. En cada

norma de liquidacin se informar la Asignacin deseada parametrizada en el esquema de orgenes. Se pueden introducir reglas de distribucin en la Norma de liquidacin. La regla de distribucin especifica que porcin de los costes de la orden deberan liquidarse a que receptores. Los costes pueden imputarse a los receptores segn las bases: 1 porcentaje 2 numero equivalente 3 cantidad fija SAP verifica que no se creen reglas que contenga distintas bases. Se pueden cambiar las reglas en la norma y se asignan a diferentes periodos de validez. Se definen los siguientes tipos de liquidacin: 1 PER. liquida los costes para el periodo que se especifica. 2 FUL. liquida todos los costes hasta el periodo. Se puede liquidar usando la clase de coste en la que se imputaron los costes originalmente o bien usando clases de coste de liquidacin. Las clases de coste de liquidacin pueden ser: 1 de liquidacin interna (21) secundarias para liquidar a ceco, pep, orden,... 2 de liquidacin externa (22) primarias para liquidar a AF o cuenta de mayor. La liquidacin crea: 1 documento de liquidacin (necesario por si hay que revertir) 2 documento FI en liquidacin externa 3 documento CO.

Budgeting - Availability Control

El sistema reconoce los siguientes tipos de presupuestos: 1 presupuesto original, el inicialmente asignado 2 presupuesto actualizado que incluye suplementos 3 presupuesto actual que incluye el original ms el actualizado. Adems tambin se pueden hacer cambios en el presupuesto original. Se puede congelar el presupuesto original con la gestin de estatus, para lo que hay que crear un estatus de usuario que prohiba la modificacin. Cuando se actualiza el presupuesto el sistema lo documenta en una partida individual. Para presupuestar rdenes hay que crear el perfil de presupuestacin y asignarlo a la clase de orden. El perfil de presupuestacin define los parmetros para la presupuestacin. En la IMG se debe definir un rango de nmeros (04). En el perfil de presupuestacin se puede definir si el control de disponibilidad no est activo, est activo o se activa manualmente o automticamente cuando se presupuesta. Se puede validar la disponibilidad de fondos tanto a nivel global como anual. En la IMG se define como opera el control de disponibilidad para una clase de orden.

1 2 3 4 5

si est activo para que transacciones aplica limites de tolerancia accin a seguir cuando se supera el lmite de tolerancia si hay costes exentos del control

Los niveles de tolerancia se definen en el perfil de acuerdo a grupos de transacciones. Se puede decidir si el sistema emite un warning, warning con mail o error si se supera el lmite. Cuando se usa el warning con mail se debe indicar un responsable del presupuesto, si no, el sistema da un error. Se puede definir un responsable para cada clase de orden y tipo de objeto. Arrastre de presupuesto: Se pueden transferir fondos al siguiente ao fiscal. SAP arrastra la diferencia entre el presupuesto y la cantidad actual para el ao especificado. No se puede arrastrar el presupuesto de rdenes completadas o marcadas para borrado, ni arrastrar cantidades negativas. Para ejecutar el arrastre se introduce el ao fiscal del presupuesto que se quiere arrastrar y la variante de seleccin que especifica qu rdenes se incluirn. El comprometido no se considera fondos que no sen han utilizado. Tambin se debe arrastrar y antes del arrastre del presupuesto. Se puede elegir diferentes monedas para la presupuestacin. Todas las partidas individuales se convierten automticamente y se guardan en la MonCO y MonObj. El control de disponibilidad no se ejecuta en la MonCO, sino en la MonObj. Esto elimina fluctuaciones por tipo de cambio.

PCA - Master Data

La contabilidad de centros de beneficio toma sus datos primariamente de procesos en otras aplicaciones (FI, LO). Ciertos parmetros se deben fijar para poder hacer uso de la contabilidad de cebes. El primer paso es establecer el nombre de la jerarqua estandard de cebes. El sistema crea automticamente el primer nodo. El cebe dummy se debe informar. Se usa para todas las contabilizaciones en las que no se ha informado el cebe, para mantener la consolidacin con FI. La eliminacin de procesos internos asegura que el sistema no imputa datos entre objetos del mismo tipo (ceco, orden) que estn asignados al mismo cebe. El tipo de moneda local define si se usa la MonCo (20), la MonGr. (30) o una moneda especial para cebes (90) como moneda para informes. Si se usa la ltima opcion habr que definir la moneda local de cebes. El sistema registra los datos automaticamente en la MonFI (local) y la moneda local de cebes. Para guardar tambin la moneda de la transaccin hay que marcar el flag correspondiente. La vista de valoracin define el enfoque usado para valorar el inventario de materiales y los movimientos de mercancas. En contabilidad de cebes se escoge una de las siguientes:

1 2 3

valoracin legal. valores el stock y los movimientos de mercancas con el mismo enfoque usado en las SocFI valoracin de grupo. valoras los movimientos dentro de filiales. No se muestran los ingresos. valoracin de cebe. puedes mostrar ingresos internos en PCA

El indicador de control activa PCA en la SocCO para un ao especfico. Si este indicador no est activo no se transfieren datos a PCA. PCA supone una divisin de la compaa en areas de responsabilidad por beneficios. Puedes dividir la compaa de acuerdo a. 1 divisin geogrfica de cebes 2 de acuerdo a productos 3 de acuerdo a funciones. 4 Cualquier otra combinacin mezcla Un cebe se define a nivel de SocCO. Cuando se crea se introduce el nombre y el periodo de validez. Se puede bloquear para imputaciones. Si un objeto est asignado a un cebe bloqueado y se intenta contabilizar contra el, el sistema muestra un mensaje de error. Por defecto un cebe se asigna a todas las SocFi. Si se intenta contabilizar a un cebe en SocFi que no tiene asignadas, el sistema no llevar a cabo la contabilizacin. PCA permite imputar datos desde el cebe dummy a otros cebes mediante distribucin o subreparto. Para el cebe dummy: 1 no se tiene que especificar periodo de validez 2 no se puede crear mediante copia de otro cebe 3 un flag lo identifica como cebe dummy 4 se crea en IMG PCA est basada en el plan de cuentas que tiene asignado la SocCO, (clases de coste primarias, secundarias y cuentas que no se usan en CO). Los grupos de cuentas en PCA se pueden copiar de los grupos de cuentas en FI o estructuras de balance y perdidas y ganancias. Se pueden asignar cebes a todos los objetos de imputacin que pueden recibir gastos o ingresos. Esta asignacin tambin determina la transferencia de partidas de balance a cebes individuales. Como resultado de la lgica de imputacin, el cebe normalmente no es imputado explcitamente. En su lugar, se deriva de los objetos que lo tienen asignado (ceco, orden). Se puede asignar cecos, ordenes, proyectos y procesos a un cebe para seguir el flujo entre FI y CO-OM desde el punto de vista de PCA. Cuando se asigna un objeto al cebe, el sistema asegura que la SocCo sea la misma. Los cecos y procesos tienen asignado el cebe en la pestalla de datos bsicos. El periodo de validez del cebe debe contener completamente al del ceco o proceso. La orden tiene asignado el cebe en la pestaa de asignaciones (igual para ordenes de mantenimiento de planta). Los objetos de coste se usan en Product Costing para recoger y guardar los costes que no se pueden asignar a objetos de un nivel ms bajo (ceco, proyecto, orden). Un objeto PA no tiene registro maestro, es una combinacin de caractersticas. Una de esas caractersticas siempre es el cebe.

En la definicin de proyecto o perfil de proyecto se puede introducir el cebe que se usar por defecto para los peps individuales. Se puede sobreescribir este valor para cada pep y si no se asigna se toma el dummy. Si el grafo cabecera no tiene asignado cebe se toma este del pep. Si el grafo actividad no tiene asignado el cebe se toma del pep, si no del grafo cabecera. La asignacin en el maestro de materiales es la base para la asignacin en ventas y produccin. Los materiales siempre tienen asignado un cebe a nivel de centro. El centro est asignada a la SocFi y esta a la SocCo. Esta SocCO debe ser la misma que a la que pertenece el cebe. Si se ha seleccionado la vista Ventas: General/Centro, el cebe se asigna en la General Plant view, si est vista no es relevante para el material, se asigna en Storage 2. Para ordenes de produccin se toma por defecto el cebe del material. Para rdenes de proceso se toma el del material principal. El cebe se guarda en el maestro de la orden (cabecera-->asignacin). Cada partida de un pedido de ventas se asigna a un cebe. Se propone por defecto el cebe del material vendido. Si se prefiere una divisin de cebes orientada a ventas en lugar de a produccin (material), se puede determinar el cebe por medio de los campos disponibles a nivel de cabecera y posicin con ayuda de sustituciones.

ESQUEMA: TFIN20_2
Planning
La planificacin es la forma de definir los objetivos de la compaa. Los resultados reales se pueden comparar con los plan mediante la planificacin. Tal comparacin puede identificar desviaciones que sirven de seal para tomar medidas correctivas. Los objetivos bsicos de la planificacin: 1 planificar la estructura de las operaciones futuras para periodos particulares 2 crear puntos de referencia para monitorizar las transacciones dentro del ao fiscal 3 monitorizar la eficiencia al final del periodo usando comparaciones plan/real y terico/real Una versin se puede contemplar como una nica imagen de costes e ingresos planificados bajo un conjunto de suposiciones. El el proceso de planificacin pueden crearse diferentes versiones con diferentes valores plan para cada una. Cada versin es independiente de las dems. SAP automticamente crea la versin 0 cuando se crea la SocCO. Los valores reales creados por las imputaciones primarias o las facturaciones internas, se registran en esta versin.

Esta versin se debe usar para comparaciones real/plan. Es la versin usado para el anlisis de datos reales. La planificacin siempre tiene lugar dentro de una versin plan. Una versin es vlida para todas las aplicaciones, lo que asegura que el uso integrado de una versin produce resultados consistentes en todas las aplicaciones. Ciertas versiones pueden tener ciertos parmetros que aplican individualmente a cada SocCO y cada ao fiscal, como la copia de versiones permitida o el bloqueo de una versin (los datos no se pueden cambiar). Si se quiere reusar grandes cantidades o parte de datos de planificaciones de aos previos en el ao fiscal actual, o si se quiere transferir valores a diferentes periodos de un mismo ao, o general versiones alternativas, se puede usar la herramienta de copia de versiones. Esta funcin tambin puede usarse para copiar datos reales desde CCA para usarse como base para la planificacin futura (se puede limitar la seleccin de datos para cecos particulares o todos los cecos). La revaloracin permite incrementar o reducir los resultados de la planficaciones en base a un porcentaje. Mediante la copia y revaloracin se pueden crear multiples versiones, lo que es til para crear versiones con para el mejor caso o el peor caso dentro del ao fiscal. El planning layout se usa para definir la pantalla de planificacin. Ya existe layouts estandars para cada propsito que se pueden copiar y adaptar o bien crear nuevos layouts. Por ejemplo el layout 1-101 se usa para la planificacin de clases de costa dependientes o independientes de actividad. Hay tres reas de planificacin en CCA. 1 clase de coste/consumo de actividad (cost elements/activity input) 2 Actividad/tarifa (activity type/prices) 3 valores estadsticos (statistical key figures) Para cada area de planificacin, se usa el layout para definir las columnas claves (las que muestran los objetos que requieren planificacin) y para ordenar las columnas de valores. Se puede controlar el proceso de planificacin usando perfiles de planificacin. En un perfil se pueden asignar tantos layouts como se requieran para cada area de planificacin. As un area puede contener mas de un layout. Se pueden agrupar varios layouts juntos asignandolos a los perfiles de planificacin. Se puede usar el perfil SAPALL para planificar en las tres areas con ms de un estandar layout. Mtodos de controlling que difieren en el nivel de detalle y las opciones de analisis: 1 cost allocations 1 solo para planificar precios de compra 2 permite comparaciones plan/real 2 internal activity allocation 1 se debe definir la clase de actividad de un ceco 2 la cantidad de actividad se tiene que planificar y reconciliar 3 puedes calcular precios automaticamente o manualmente 3 fixed and variable costs 1 basado en costes plan dependientes o independientes de actividad 2 permite componentes fijos y variables en la tarifa de la actividad 3 permite comparaciones plan/real 4 costes marginales

Planificar valores estadsticos permite: 1 calcular ratios en CCA como costes por empleado 2 crear bases receptoras (allocation factors) para facturaciones como distribucin o subreparto Se define el valor estadstico como de valor fijo o total: 1 si planificas valores fijos (empleados) se debe introducir el nmero asignado al ceco. El sistema entonces muestra el valor para todos los periodos planificados en la pantalla resumen (overview screen). La pantalla de periodos muestra la cantidad plan para cada periodo 2 si planificas valores totales (pasos de telfono) la cantidad se distribuye a los periodos de acuerdo a una clave de distribucin. SAP proporciona layouts para planificar valores estadsticos que se acceden via perfil SAPALL: 1 1-301 . para valores independientes de actividad 2 1-302 . para valores dependientes de actividad Tambin se pueden transferir valores estadsticos desde el sistema de informacin logistico (LIS) Se planifican costes primarios independientes de actividad estructurados por clase de coste en cecos a los que ms tarde se le imputan datos reales (planificaci -> clase de coste/consumos de actividad). En distribucin y subreparto los costes planificados en cecos por medio de keys definidas por el usuario (porcentajes, cantidades o valores estadsticos) se facturan. La ventaja de estos mtodos es que son simples, slo se necesita definir la clave y la relacin emisor/receptor. Pure cost allocation:Los metodos de cost accounting que estn basados en facturacin de costes puro no necesariamente requieren planificacin. Sin embargo, hay muchos tipos de facturacin de costes, como distribucin y subreparto que son solo posibles en CO-OM. Por esta razn, slo se recomiendan para relativamente simples sistemas de costes que no necesitan especial integracin con otros componentes. Para facturacin de costes el sistema proporciona diferentes funciones como distribucin, subreparto o recargos. Las clases de actividad se usan como medidas de la funcin de un ceco. Describen el consumo de actividad de un ceco y se usan para el clculo de ratios operativos y costes tericos. La clase de actividad se factura usando la clase de coste de su maestro. Cuando se planifican clases de actividad, gestionas la actividad de un ceco midiendo y controlando su consumo de actividad. Se puede introducir el precio para cada ceco/actividad tanto manualmente o usando calculo del precio automtico. Para la planificacin de clases de actividad, SAP proporciona el layout estndar 1-201 que est asignado al perfil SAPALL. Cuando se planifican costes primarios que son dependientes de actividad, planificas ciertos costes que dependen de cierta actividad proporcionada por el ceco. Una vez que la planificacin de la actividad est completa, puedes planificar los costes en linea con esta actividad. Los costes variables son costes que ocurren en relacin a la actividad planificada. Estos costes pueden planificarse adems de los costes que no son

dependientes de actividad. Esto significa que el precio puede contener dos tipos de costes fijos: 1 costes plan (dependientes de actividad) para el ceco 2 partes fijas de costes plan dependientes de actividad para la clase de actividad. SAP proporciona el layout 1-101 (en SAPALL) para planificar costes primarios dependientes de actividad. Adems de costes primarios, un ceco puede incurrir en costes secundarios si tiene que usar servicios de otros cecos (activity input). Se puede planificar este tipo de consumo de actividad tanto dependiente como independiente de actividad. Planificas consumos como independientes de actividad si usa servicios como horas de mantenimiento sin importar la actividad del ceco receptor. El consumo de la actividad, en este caso es fijo. El consumo de actividad se planifica como dependiente de actividad si el consumo depende de la prestacin de actividad en el receptor. El consumo puede ser fijo o variable para la cantidad de actividad prestada. Para calcular los costes secundarios, SAP multiplica el precio de la actividad del emisor con la cantidad de actividad consumida por el receptor. Los costes secundarios (independientes de actividad) son siempre costes fijos para un ceco receptor. Se puede usar el layout 1-102. Los nmeros equivalentes son una forma de asignar costes plan independientes de actividad clases de actividad (splitting) Pasos tpicos en la planificacin de cecos: 1 El primer paso involucra la planificacin de valores estadsticos (ratios en distribucin y subreparto) 2 Asignar clases de actividad a cecos y planificar su consumo. Es necesario saber que actividad puede proporcionar un ceco 3 Reconciliacin. con el plan de reconciliacin la actividad planificada para el ceco se ajusta a la actividad prevista del receptor 4 planificacin de costes primarios. Se pueden planificar manualmente tanto dependientes como independientes de actividad. Se puede subdividir los dependientes en costes fijos y variables 5 planificacin de secundarios que pueden incluir subreparto o facturacin indirecta de actividad 6 clculo automtico del precio. Se calcula iterativamente para todos los cecos y actividades Asignando mtodos de planificacin a los controlling methods: En escenarios simples, la planificacin es opcional y no son necesarias clases de actividad, slo los costes se planifican con distribucin o subreparto. Si quieres tambin usar controlling por objetos de coste necesitas poder imputar los recargos generales a ordenes de produccin y otros objetos de coste. La ventaja de la facturacin de clases de actividad es que tiene en cuenta tanto cantidades como flujo de valores. La actividad requerida se especifica en la hoja de ruta que proporciona infomacin detallada de costes en product cost planning y en objetos de coste. La clase de actividad puede consumirse por cecos u ordenes. Cuando se planifica la actividad, la cantidad de actividad que otros objetos han planificado consumir se muestra en el emisor como cantidad prevista. Se puede usar el plan de reconciliacin para ajustar la cantidad de actividad plan y la cantidad de actividad prevista. Despus que se hayan planificado los costes y las actividades, el sistema puede calcular la tarifa dividiendo los costes plan por la cantidad de actidad prestada. Si un ceco ha proporcionado ms de una actividad, debes primero particionar el coste a las diferentes clases de actividad usando nmeros equivalentes o la herramienta de particin.

Mtodos ms detallados proporcionan ms informacin sobre costes, actividad prestada y ratios. Para localizar el nivel de operacin de un ceco en el anlisis de costes reales, el proceso de planificacin debera clasificar los costes plan y la actividad consumida tanto como dependiente de actividad como independiente. Esto dar la informacin necesaria para calcular los costes tericos. Un cambio en el nivel de operacin para una actividad resultar en un cambio de los costes tericos. El ratio de operacin representa la cantidad de actividad real de una clase de actividad en un periodo dividido por la cantidad plan de la actividad. Los costes tericos (costes fijos plan + costes variables plan*ratio de operacin) son los costes que se esperan par cierto ratio de operacin. Estos forman la base de las comparaciones terico/real. Easy Cost Planning facilita la entrada de datos en el sistema. Con el Execution Services el sistema propone automaticamente los datos a contabilizar. Los datos propuestos se basan en los datos planificados con la easy cost planning tool. Easy Cost Planning y Execution services trabajan de la siguiente manera: 1 el modelo de costes est definido como estructuras cuantitativas que dependen de bases de imputacin (cost drivers) 2 easy cost planning usa estos costing models 3 los costes reales se registran usando el execution services en base a los datos plan Este metodo se corresponde a la planificacin que usa unit costing. Sin embargo se puede usar estructuras cuantitativas (costing models) predefinidas y tener la cantidad de recursos dependiendo de cost drivers planificados. Puedes predefinir estructuras cuantitatidvas para easy cost planing usando costing models (formularios de planificacin llamados templates en el que controlas cantidades, tarifas y la entrada mediante formulas o condiciones)

Integrated Planning Process

El ciclo de planificacin integrada comienza con el plan de ventas. El SIS, un componente del LIS, la compaa planifica las ventas a nivel de producto o grupo de productos para el siguiente ao. Similarmente, la planificacin de ventas se puede llevar a cabo en PA. El plan de ventas del SIS y COPA se pueden comparar y transferir al Sales Operations Planning (SOP). En cost center planning, las cantidades de actividad planificadas se determinan en base a las cantidades planificadas en SOP. La planificacin de costes se realiza para cecos, rdenes adems de adicionales actividades de planificacin en CO-OM. Los costes planificados en HCM y AM se pueden transferir a cost center planning. La tarifa plan se calcula entonces. El calculo de la tarifa plan se transfiere a Product Cost Planning, que estima los costes de produccin usando la lista de materiales y la hoja de ruta. Los costes de los productos terminados que se calcularon en base al plan de ventas se trnasfieren entonces a PA. Se puede usar el resultado de este plan para hacer ajustes al plan original que ejecutado completa el ciclo de nuevo. Para dar soporte a los pasos individuales en el proceso de planificacin en PA, las herramienta de planificacin en PA proporciona numerosas funciones y ayudas a la planificacin que se pueden usar para crear o cambiar datos plan. Esto incluye tanto la creacin automtica como manual de los datos, adems de la introduccin descentralizada de datos mediante excel que se cargan en SAP.

Con la distribucin top-down los datos planificados en PA a un nivel se distribuyen a otros niveles en base a datos de referencia que se deben especificar y cuyo valor se usa como distribution basis. Se puede transferir cantidades del plan de ventas de PA a SOP tanto para productos individuales como a nivel de grupo de productos. Se puede transferir dato para un centro o varios centros. Si no planificas a nivel de centro en PA, las cantidades planificadas se distribuyen a los centros, y si es necesario realizando conversiones de unidades de medida. Se usa los siguientes datos en integrated planning: 1 maestro de materiales (se usa para representar materias primas, productos semiterminados y productos) 2 BOM (lista de componentes de un producto semiterminado o producto) 3 Work centers (lugar fsico en el que se realiza una operacin. est vinculado al ceco y sus actividades lo que permite el calculo de la tarifa de la actividad) 4 Routing. (secuencia de pasos en el proceso que determina las cantidades de actividad usadas) Usando la cantidad de actividad esperada, las cantidades de actividad proporcionada para un ceco se pueden planificar. Esto se puede hacer automticamente usando la reconciliacin o manualmente. Tras la planificacin de las cantidades de actividad, los costes se planifican. El responsable del ceco no planifica todos los costes manualmente, muchos costes se toman de otros componentes (HCM, AM, integrated planning for orders y plan-integrated WBS elements). Una vez planificados los costes la tarifa se calcula. Para ser capaz de usar integrated planning, se tienen que cumplir unos requerimientos en CCA y otros sistemas. Por ejemplo, si quieres transferir valores plan de valores estadsticos, debes primero crear el maestro y vincularlo con el LIS. La integracin entre CCA y HCM permite la planificacin de costes de personal y transferirlos a CCA. La integracin entre CCA y AM permite transferir cargos e intereses por depreciacin a costes primarios en CCA. Los costes se planifican normalmente para ordenes de ciclo largo, para ordenes de vida corta no se suelen planificar. Hay tres niveles de planificacin para rdenes internas: 1 overall planning es el modo ms simple. puedes estimar valores totales y anuales independientemente de clases de coste 2 si est disponible informacin detallada para las ordenes se puede usar primary/secondary cost and revenue planning 3 Con unit costing puedes hacer una planificacin ms detallada con clases de coste. Se activa la planificacin integrada en la versin plan Production planning usa datos maestros de otras aplicaciones: bom, routing, work center de production planning y cecos, clases de actividad y procesos ABC de CO-OM. Se pueden usar varias herramientas para product cost planning dependiendo de los datos disponibles: 1 product costing with quantity structure. los costes se calculan para el material via derivacion de las cantidades dle bom y del routing. si se dan ciertos prerequisitos el resultado puede actualizar el precio estandar u otro campo en el maestro del material.

2 3

product costing without quantity structure. los costes se calculan para un material sin estructura que se derive automaticamente. se debe introducir manualmente o copiarla de un template. Tambin puede actualizar el precio estndar reference and simulation costing. los costes se calculan para un objeto abstracto conocido como base planning object. introduces manualmente la estructura o la copias de un template. el resultado se puede usar en otros costing.

Cuando creas un cost estimate con estructura cuantitativa, necesitas introducir la costing variant, el material, el centro y el lot size. Las fechas se proponen de la costing variant y determinan: 1 periodo de validez del cost estimate (costing date from/to) 2 periodo de valides del bom y routing (quantity structure date) 3 pricing date para los componentes del material y actividades (valuation date) Se usa el transfer control indicator para especificar que quieres usar un cost estimate existent o crear uno nuevo. Puedes analizar el resultado en el sistema de informacin. El resultado se puede salvar y mostrar por itemizacin, por clases de coste o cost component splits. La itemizacin muestra informacin detallada sobre el origen de los costes tal como cantidades y precios de los materiales y actividades. La itemizacin por clases de coste agrupa los elementos idividuales en clases de coste que se determinan via determinacin de cuentas del material, o del maestro de la clase de actividad o va planificacin de la actividad o maestro del proceso ABC. El cost component split agrupa las clases de coste en cost componets. Se puede usar costing sheets para calcular recargos generales. Usando el metodo tradicional, aplicas un recargo como un porcentaje o cantidad. En el costing sheet determinar como el recargo se calcula para los COGM y COGS. Se asigna a la valuation variant que est asignada a la costing variant. Cuando creas un material costing que usa esta costing variant, la costing sheet asignad se usa para el calculo de los recargos (el sistema usa G como item category). Cuando se crea un cost estimate para un BOM, los costes se agrupan hacia los componentes superiores de la jerarqua, los cost components del cost component split se trasladan hacia arriba para estimar el coste del nivel ms alto del material (cost rollup). Esto asegura que todos los costes de los GM de todos los materiales en un multinivel BOM se incluyen. Marcar y liberar el cost estimate actualiza el precio estandar del material en su maestro. Esto revalora las existencias en FI. Se tienen que dar los siguientes prerequisitos: 1 el estandar cost estimate no debe tener errores (estatus CT) 2 marcar y liberar debe ser fiable. La SocFi y periodo en el que la estandar cost estimate puede marcarse con la valuation variant establecida se pasa a autorizacin para marcar. Esto se debera hacer una vez por periodo por la persona responsable. Si marcas el resultado actualiza el precio estandar futuro en el maestro del material Cuando liberar el precio futuro pasa a precio estandar actual. Solo se puede liberar un estandar cost estimate una vez por periodo a menos que borres el previo con un programa especial. Los cost component del material costing se pueden usar en PA para valorar los datos plan o reales de la facturacin. Esto permite ver informacin detallada en PA sobre el origen de los costes de los productos y analizar su contribucin al margen. Para transferir los costes de materiales a PA, asignas los cost components con la COGM y los costes de ventas y administracin a los campos valor.

La planificacin de cebes involucra dos pasos: los datos plan se transfieren a los cebes desde CCA, Internal orderes, PA y CO-PC. Los datos de planificacin se pueden modificar entonces directamente en los cebes.

Introduction to Product Cost Planning

Si se planifica un nuevo producto para el que no existen datos maestros en SAP, se puede realizar una planificacin inicial de costes creando un Base Planning Object usando Reference and Simulation Costing. Usando este mtodo planificas manualmente los costes para cada elemento. Cuando el primer maestro de material se ha creado en SAP, se puede usar Material Cost Estimate without Qty. Structure para planificar manualmente los COGM y COGS para el producto. Puedes usar un base planning object como base de referencia. Hay dos mtodos disponibles para el Material Cost Estimate without Qty. Str: Single y multilevel unit costing. El multilevel unit costing permite planificar los costes a nivel de productos semiterminados sin requerir la produccin de BOMs. Cuando el dato maestro est completo (BOM y routing) y disponible en el sistema, se pueden crear Mat. Cost Estimates with Qty. Structure. Esto calcular automticamente los COGM y COGS de los datos contenidos en las aplicaciones logsticas. En las primeras fases del ciclo de vida de un producto, unit y multilevel costing son mtodos idneos ya que permiten: flexibilidad, mantenimiento de datos eficientes, el usuario puede detallar y refinar la estimacin y el acceso a existentes datos y cost estimates del sistema.

Reference and Simulation Costing

Cada cost estimate se basa en una costing variant. En la costing variant se combinan varios parmetros de control para el calculo del coste. Estos parmetros contienen informacin como los precios usados por el sistema para el coste del material, actividades y procesos. Los parmetros de control y los settings de la costing variant dependen de si se crea un material cost estimate o un base object cost estimate. Cada costing variant contiene una valuation variant y un costing type. Una costing variant para material cost estimates contiene importantes parmetros de control para la determinacin automtica de la estructura cuantitativa y la actualizacin de precios en el maestro de materiales. La valuation variant determina el precio al que son valorados los materiales, actividades, procesos, subcontratacin y actividades externas. El costing type determina el propsito del costing, como base object costing o material costing y actualizacin de precios. Un cost estimate identifica los recursos requeridos para producir un producto o servicio. Estos elementos pueden usar datos maestros y precio existentes en el sistema tal como tarifas de actividad de CCA o precios de materiales de MM. Dependiendo del item category, la pantalla de detalle de un costing item contiene: item category (requerido para cada item), recurso (como material o ceco) work center (para actividades procesadas internamente) centro, clase de coste, cantidad, unidad de medida, precio total, precio fijo, valor total, valor fijo y moneda.

En base planning costing se introducen los siguientes datos maestros para la aplicacin de recargos: costing sheet y overhead key. El sistema encuentra la clase de coste de los elementos individuales como sigue: 1 base planning object. su dato maestro 2 actividad interna. maestro 3 actividad externa. manual 4 subcontratacin. manual 5 recargo. costing sheet 6 manual process cost. manual 7 automatic process cost. process template 8 material. determinacin de cuentas 9 servicio. maestro 10 elemento variable. manual Cuando se crea un base planning object se generan datos maestros. Estos datos maestros estan en la forma de textos asignaciones y unidades de medida del base plannign object. El base planning object est siempre asignado a la SocCO. Seleccionando la costing variant: 1 establecen la estrategia de valoracin para los elementos 2 se mantiene en la IMG 3 se debe introducir el lot size La cabecera del cost estimate se crea automaticamente. Se puede usar para: 1 introducir el pricing date 2 cambiar el lot size 3 introducir diferentes textos. Hay dos opciones para introducir elementos en unit costing: list screen, disponible en tres vistas (recursos; textos, variable items, totales; formulas simples) y detail screen. Se introduce un item category para cada elemento del cost estimate. El item category determina que datos introduces y que datos se leern del sistema y como se calcularn los costes.

Material Cost Estimate Without Quantity Structure.

Los material cost estimates se guardan con referencia a una planta, los productos producidos en ms de una planta tienen separados cost estimates en cada planta. Para valorar los movimientos en logstica, el sistema accede al resultado del costing. La valuation area determina el nivel organizativo al que el material se valora. Para usar material costing, es obligatorio que se establezca cada planta como area de valoracin. Vistas relevantes a costes en el maestro de materiales: 1 accounting view. relevante para la valoracin del material, control de precios y determinacin de cuentas 2 costing view. parmetros de control para material costing, caractersticas requeridas en Cost Object Controlling. Debe ser mantenida para poder costear un material.

MRP view. Estatus del material en PP, scrap factors, special procurement, Indicadores (co-product/bulk material), Product version.

La clase de material determina si la costing view est permitida para un material. Contiene valores por defecto usados cuando se crea el material. El lot size introducido se usa como valor por defecto en el material cost estimate, aunque se puede sobrescribir en tratamientos individuales (no es procesamiento en masa). La clase de valoracin controla la determinacin de cuentas. Se determina la cuenta de consumo del material, que tamben aparece como coste primario en la itemizacin. El price control indicator controla la valoracin del inventario del material. Dos opciones: precio estndar y precio medio variable. Un inventory cost estimate puede usar el tax-bases y comercial prices para valorear y actualizar el costing result para productos terminados o semiterminado en estos campos. Los planned prices 1, 2 y 3 se pueden mantener para materias primas y partes compradas y usarse para valorar materiales en el cost estimate. Material costing without qty. structure est diseado para cost materials que no tienen boms y/o routing. El resultado puede escribir los price fields del material costing. Si bom o routing no existen, se pueden crear los items manualmente, que representarn la estructura y se valorarn con el cost estimate. La seleccin del precio y calculo de recargos se determinan automaticamente y se basan en la valuation variant asignada a la costing variant. Se puede usar material cost estimates without qty. structure: 1 para el costing y actualizacin de precios de nuevos materiales 2 cuando se quiere realizar el costing usando datos de planificacin de la produccin non-SAP. Pasos a seguir. Single-level 1 introducir material y planta 2 seleccionar la costing variant que establecera la estrategia de valoracin para los costing items, propone fechas de valides para el cost estimate, y fechas de valoracin de materiales y tarifas de actividades. si no se introduce el lot size se toma del maestro del material. 3 Se crea automaticamente la cost estimate header, que se puede usar para cambiar el lot size e introducir varios textos. 4 cuando se salvan los costing items, se calcula automaticamente el recargo y process cost. La itemizacin y cost component split estarn disponibles para anlisis. 5 Despus de salvar los costing items, el material cost estimate se actualiza en la base de datos. El multi-level unit costing es una pantalla altamente flexible que permite la edicin de la estructura jerarquica de base planning objects y materiales sin bom y routing. Single-level costin solo proporciona la edicin de un nico base planing object o material. Multi-level unit costing se puede usar en los siguientes escenarios: nuevo producto, productos similares, cambios en productos. Pasos a seguir. Multi-level

1 2 3 4 5 6

prerequisito. material con vista de costes (vista de contabilidad recomendada) seleccionar la costing variant. que establece la estrategia de valoracin para los costing items y se mantiene en la IMG. Se introduce el lot size se crea automaticamente el cost estimate header. se puede cambiar el lot size y varios textos insertar material cost estimates desde la worklist (drag&drop). Es sistem pregunta si se usar el original o una copia. Hacer los cambios oportunos. Introducir las cantidades restantes en la list screen del unit cost estimate. tras salvar, es cost estimate se actualiza en la base de datos.

Estructura de pantalla del multi-level unit costing (3 areas). 1 costing structure. el sistema puede mostrar simultaneamente un multi-level bom, multiples cost estimates (con o sin estructura) y base planning objects. Permite rapidamente editar la jerarqua. 2 unit cost estimate o cost estimate header. 3 worklist o detail list. Costing results: 1 itemizacin. proporciona datos detallados sobre los recursos requeridos para producir un producto. La informacin para cada item incluye detalles como cantidad, unidad de medida o valor. El report puede incluir la clase de coste asignada a cada item. 2 costed multilevel bom of material report. proporciona un resumen jerarquico del valor aadido para cada elemento material. Los costes para cada componente se basa en la estructura y contenido del bom. 3 cost component split (disponible para cost estimates con o sin estructura cuantitativa). agrupa las clases de coste en cost component. cuando se calcula el coste del multi-level structure, la cost component split " se enrolla" (rollup) para retener para analisis la identidad original de los costes desde los niveles ms bajos. Para cada producto, el cost component split proporciona: 1 el valor aadido del material (nivel ms alto) 2 los costes de los materiales subordinados en el bom (nivel ms bajo).

Preparing for Product Cost Planning

Cuando se crea un cost estimate, siempre est vinculado a un costing variant. La costing variant contiene toda la informacin requerida para ejecutar un material cost estimate. Se define y chequea en la IMG. Componentes de la costing variant:

costing type. 1 update prices. especificar el precio que se actualizar en el maestro del material. 2 date of update. especifica la fecha en que el cost estimate se guard en la base de datos 3 otros: cost portion overhead (especifica la cost component view que estar sujeta a recargos), partner cost component split valuation variant. determina el precio que se usar para valorar materiales, clases de actividad, procesos, subcontratacin y actividades externas. Busca varias fuentes de precios segn una estrategia de secuencia. El primer precio encontrado ser el usado.

Date control. Determina las fechas propuestas por el sistema y si se pueden modificar 1 Para material costing with qty. structure: periodo de validez del cost estimate qty. structure date. la fecha en que se determina valuation date. 2 Para material costing without qty. structure periodo de validez valuation date Further settings. 1 qty. structure. especificas si el lot size se pasar. Eso slo es necesario para cost estimates with qty. structure y sales order costing. 2 additive costs. material costs que se pueden introducir manualmente en un unit costing y entonces aadirlos (automaticamente) al cost estimate with qty. structure. 3 update. especifica si est permitido grabar para la costing variant. si est permitido el sistema siempre graba un cost component split. Sin itemizacin, no se puede mostrar costed multi-level boms o itemization reports. 4 assigments. se puede mantener settings y asignaciones de la costing variant: cost component structre costing version si la cost component split est activa en la moneda de la SocCO si se requiere cross-company costing 5 otros: gestion de errores.

Propsitos de varios cost estimates: 1 standard cost estimate. valoracin de las cantidades planificadas con precios planificados. calculo de precios estandars para la valoracin S-price del material 2 modified standard cost estimate. valoracin de la estructura cuantitativa vigente con precios planificados. Costing de materiales durante el ao fiscal para analizar el desarrollo de los costes 3 current cost estimate. valoracin de la estructura cuantitativa vigente con precios actuales. Costing de materiales durante el ao fiscal para analizar el desarrollo de los costes. 4 inventory cost estimate. valoracin de la estructura cuantitativa real con tax-based y commercial prices. inventory valuation. En multilevel costing structures, la cost component split proporciona informacin sobre los costes de los componentes originales. Cada linea de una itemizacin, est as asignada a un cost component como se define en la cost component structure. El proposito del cost rollup es asegurar que todos los COGM y todos los materiales en el multi-level bom se incluyen en el cost estimate al ms alto nivel. Esto se lleva a cabo asignando los costes a cost components. Los cost components se establecen agrupando clases de coste. Para cada material, la cost component split proporciona informacin sobre: 1 el valor aadido del material (upper level) 2 los costes de los materiales subordinados (lower level) Un mximo de 40 costs fields se pueden llevar hacia arriba (rollup) en un cost component split. Un cost component puede llevar costes fijos y variables. Vistas del Material Cost Estimate: Un cost component view consiste en la combinacin de cost components basada en varias caracteristicas. Esto crea un filtro en el sistema de

informacin para que slo los datos asignados a la vista se muestren. en el cost estimate header, se pueden mostrar hasta 5 vistas como initial costing result. Se asignan estas vistas en el Settings men en el cost estimate header. Vistas disponibles: 1 cost component split 2 itemizacin 3 costed multilevel bom La cost component divide la costing result en grupos de costes de materiales, maquina, personal, produccin, recargo y actividades externas. Las clases de coste se asignan a la cost component en la cost component structure. Para cada cost component se determina los siguiente: 1 si los costes se pasarn al nivel ms alto (rollup) 2 si los costes incluyen el precio estandar o el inventory price 3 las vistas del cost estimate en el sistema de informacin 4 los cost component groups a los que est asignado el cost component 5 si es relevante para el inventario y los COGM 6 si debera contener cantidades totales o fijas o variables. Un cost component structure se asigna a cada costing variant. Tambin puedes asignar varios cost component structure para cada SocFI y Planta. Para standard cost estimate (costing type 01) slo se permite una cost component por cada SocFI. Se tienen que cumplir ciertos requerimientos para crear primary cost components splits. 1 asignar una cost component structure en la versin CO en cost center y process cost planning 2 determinar los precios mediante iteracin de precios planificados 3 definir una cost component structure para la primary cost component split de Produc Cost Planning 4 definer una transfer structure para la transferencia de cost component en cost center y activity-based costing a los cost components of primary cost component split en PC planning. Cuando se crea un material cost estimate, puedes decidir si el sistema debe crear una cost component split solo para los COGM, slo para un primary cost component split o ambos simultneamnente. Esto se hace cuando asignas la costing variant y introduces la cost component structure para la cost component split principal y auxiliar. Overhead costing es uno de los mtodos para facturar costes indirectos cost estimates. Esto requiere aplicar porcentajes o importes fijos basados en cantidad para especificar la base del coste. Las reglas para aplicar recargos se sumarizan en la overhead costing sheet. Detalle: 1 Calculation base. combinas clases de coste en filas, deforma que se puede particionar las clases de coste por origen. Se puede dividir tambin por costes fijos o variables 2 Overhead. Se calcula el recargo en las lneas de la calculation base. aplicas porcentajes o importes basados en cantidad (100USD por cada 30 piezas) 3 Credit. Asignas la credit key para cada lnea de recargo en la costing sheet. La cantidad de recargo es abonada a un ceco, proceso u orden bajo una clase de coste secundaria.

Material Cost Estimate With Quantity Structure

El resultado de una material cost estimate con estructura cuantitativa no difere de aquellos sin estructura cuantitativa; son idnticos desde el punto de vista del costing (itemizacin, cost component split, costed multilevel bom). Es slo el mtodo de obtener el costing result el que difiere. Material costing with qty. structure puede determinar la estructura de productos y planes de produccin de LO, y convertirlos en estructuras de itemizacin y cost component split. BOM: Lista de materiales. Es un directorio para un objeto y sus partes constituyentes que contiene informacin como el nombre, nmero de referencia, cantidad y unidad de medida. Se usa para requerimientos de planificacin, production for staging parts y calculo del coste de materiales. Los costing levels se determinan automticamente cuando se crea el cost estimate. Asignando materiales a los costing levels se asegura que el costing se lleva a cabo en la secuencia correcta: materias primas, partes compradas, productos semi-terminados y finalmente productos terminados. La cabecera del BOM contiene informacin que aplica a todos los elementos del BOM. El bom status debe estar activo para costing para permitir que se lea el BOM en un cost estimate. Tambin se define en la cabecera el BOM usage, el rea de validez (slo un bom se puede usar para costing lot size definido) y el alternative bom. Item category: L stock item; N non-stock item; R variable-size item. Fixed quantity indicator. Indica si la cantidad introducida depende del lot size. Relevancy to costing indicator. Si no est marcado el sistema ignora el BOM item en el material cost estimate. Los costes de produccin se determinan mediante la hoja de ruta, el centro de trabajo en el que se realiza la operacin, el centro de coste y la clase de actividad relevante. El routing consiste de una o mas operaciones. Cada operacin contiene informacin acerca del work center, recuersos de produccin, herramientas, materiales asignados, textos y valores estandars (como y cuanto). El work center (machine group o planner group) est definido con referencia a una planta y tienen asignado un ceco. Su standard value key permite definir hasta 6 valores estandar para una operacin. El control key especifica las funciones que se quieren ejecutar con una operacin. La hoja de ruta puede contener multiples materiales involucrados en el mismo proceso de produccin. Se usa la task list usage para asignar routings a varias work areas, de esta forma puedes crear varios routings para producir un material de planta, que se diferenciarn por la task list usage. El routing status indica la fase del proceso. Si el control key especifica que la operacin no es relevante a costes, el relevancy to costing indicator se ignora en la operacin. Si el contro key especifica que la operacin es relevante a costes puedes invalidarlo con el relevancy to costing indicator en la operacin. La versin de produccin se mantiene en el maestro del material (MRP view 4, Costing view 1). Cmo se encuentra el BOM?

La quantity structure control es un proceso por el que el sistema busca alternativos BOM y/o routings si hay varios disponibles para el material. Se introduce el qty. structure control ID en la costing variant. Este ID describe la lista de prioridades para el BOM y routing a travs de selection keys. El BOM application determina por medio del un selection ID que BOM usage se selecciona primero. Criterio estndar: periodo de validez (el bom debe ser valido en la qty. structure date), lote size range y el estatus debe permitir el costing. Cmo se encuentra el routing? Si la versin de produccin se encuentra o est definida, se usa el routing contenido. El selection ID para el routing determina que routing se selecciona primero. Criterio estandar: periodo de validez, lot-size range y el estatus debe permitirlo

Prerequisito para el material cost estimate with qty. structure: Maestro de materiales con vistas de costes y contabilidad Cuando se crea un cost estimate with qty. structure, se introduce la costing variant, el material y la planta. Las fechas se proponen de la costing variant y determinan: el periodo de validez del cost estimate (costing date from/to), la determinacin de la estrucutra cuantitativa (qty. structure date), la valuation date para materiales y actividades. El sistema determina y valora la estructura cuantitativa automaticamente. El cost estimate no se actualiza en la base de datos hasta que se salva. Error log. Hay dos opciones para analizar errores en el cost estimate: Overall log (lista completa de mensajes para todos los materiales) o por doble click del material en el header del cost estimate o en el estatus display. Se pueden analizar los costing results con reports estandars y display variants. Planned prices 1, 2 y 3 se pueden usar para materias primas o partes compradas para valorar materiales en el cost estimate. tax-based y commercial prices. Estos precios se introducen para partes compradas en inventory costing para determinar valores como el valor ms bajo. Inventory costing usa estos precios para valoracin y actualiza el costing result para estos campos. Price control. Indicador que controla que precio se usa para valorar el inventario de un material. Opciones: precio estandar y precio medio variable. Estos precios se usan para valorar los movimientos de mercancias en SAP y para valorar el stock. Un estandar cost estimate puede usarse para actualizar el precio estandar. Dependiendo del proposito del cost estimate el resultado puede escribir los price fields en el maestro de materiales. El costing type determina cual, si alguno, de los price fields se actualizaran con el resultado del cost estimate. Se puede actualizar: 1 el resultado del estandar cost estimate como precio estandar 2 el resultado del modi. cost. est. o el current cost est. como planned prices 1, 2 y 3. 3 El resultado del inventory cost. est. como commercial prices 1, 2 y 3 o tax-based prices 1, 2 y 3 El precio estandar se actualiza en dos pasos: marcar y liberar el estandard cot estimate. El control de precios juega un rol crucial en la valoracin de materiales. CUando el price control indicator es "S", el stock se valora al precio estandar. Adems, los movimientos de mercancas se valoran usando el precio seleccionado de acuerdo con el price control indicator.

Si el precio estandar se actualiz por un estandar cost estimate, se puede usar en Cost Object Controllng. El sistema puede usar la itemizacin del estandar cost estimate para determinar los costes tericos de las ordenes de produccin. La diferencia entre los costes tericos y los reales se pueden analizar a nivel de categorias de desviacin, como desviaciones de precios o cantidades. La itemizacin salvada proporciona la base del calculo de desviaciones. Procedimiento para actualizar el S-Price: ejecutar el material cost estimate, chequear posibles errores (los errores de contenido como precios o cantidades no los detecta el sistema), actualizacin permitida, esto se lleva a cabo por SocFI, valuation variant y costing version. Asegurar que la valuation variant se usa en la costing variant. Marcar y liberar.

Costing Run
Es una herramienta para el procesamiento en masa en Product Cost Planning. las siguientes situaciones son ejemplos de uso: 1 sce para todos los materiales de una planta 2 sce para todos los materiales de todas las plantas 3 mensual mod. ce para todos los materiales 4 current ce para todos los materiales de un grupo de productos 5 current ce para estructura de productos altamente complejas Despus de la costing run y su procesamiento completado con exito, se puede borrar. Los datos administrativos tambien se borran, pero los material cost estimates generados permanecen y se pueden reorganizar y/o archivar. Hay una transaccin a parte para mantener los parametros para seleccionar materiales y generar la selection list (ckmatsel). La seleccion de materiales se puede restringir por: 1 nmero de material, planta 2 bom usage 3 campos del maestro de materiales adicionales de las vistas de costes y contilidad (cebe, valuation class,..) 4 criterios de cost estimates existentes (costing variant, costing dates, costing status) 5 referenciando materiales de otros costing run Despus de que la lista inicial se haya creado, es posible editar manualmete la seleccin list (ckmatcon) aadiendo o borrando materiales de la lista. La selection list se puede usar para seleccionar materiales para una costing run (ck40n) asignando la selection list al selection step. La costing run se identifica por su nombre y costing run date. Datos generales: 1 la costing variant especifica las estrategias de explosin y valoracin 2 se necesita introducir slo la SocFI si el costing run deberia limitarse a una company code y cross-company costing no se ha establecido en la IMG. 3 similarmente se necesita introducir el server group si se usa procesamiento en paralelo. Antes de iniciar la costing run, se necesita guardar los datos generales.

El costing result area permite analizar el resultado de un procesamiente. Hay tres reports disponibles: 1 costing levels. resumen del numero de materiales seleccionado y costing levels creados 2 material lists. materiales seleccionados 3 analysis.permite comparar costing results con el resultado de otros costing run o con los precios del maestro de materiales. El sistema proporciona varias variantes de este report (results of costing, price vs cost estimate y variances entre costing runs).

Transfer Control
En la IMG puedes especificar que cost estimate se usa. Puedes definir la estrategia en el transfer control para transferir los siguientes cost estimates: 1 future, current, previous standard cost estimates (costing type 01) 2 cost estimates con period-based transfer control. Puedes definir la estrategia como sigue: 1 transferir cost estimates en la misma planta 2 transferir cross-plant cost estimates. Aplicacin: 1 material cost estimate with qty. str. 2 material cost est. without qty. str. 3 Costing Run 4 cross-company costing 1 cross-plant 2 cross-company code 5 reference variant

ESQUEMA: TFIN22_2A
PROFITABILITY MANAGEMENT

COSTING-BASED PA: Objetivo: Market profitability; Mtodo: Cost-of-Sales; Objetos de anlisis: Segmentos; Ratios: Profit-Related key figures. Monedas (de la SocPA, SocFi) todas las cantidades se guardan en la MonPA y se puede configurar para que tambin se guarden en la Mon SocFI.; Aspecto organizativo: SocPA; Reconciliacin con FI: valores imputados y estimados. ACCOUNT-BASED PA: Objetivo: Market profitability; Mtodo: Cost-of-Sales; Objetos de anlisis: Segmentos; Ratios: Profit-Related key figures; monedas (MonTX, Mon SocFI, Mon

SocCo). Todas las transacciones se llevan a cabo en las tres monedas; Aspecto organizativo: SocCO. Reconciliacin con FI: valores imputados EC-PCA:Objetivo: Enterprise Controlling; Mtodo: Cost-of-Sales o Period Accounting; Objetos de anlisis: Cebes; Ratios: Profit-Related and financial key figures; Monedas (Tcode, SocFI, MonPC)Todas las transacciones se llevan a cabo en las tres monedas; Aspecto Organizativo: SocCo; Reconciliacin con FI: Valores imputados. Los dos mtodos contables usados para generar estados de rentabilidad son los mtodos de costes de ventas Cost-of-Sales y period accounting method. La diferencia est en cmo el beneficio y la perdidas totales se representan. Cost-of-Sales: Con este mtodo el enfasis est en la reconciliacin de los ingresos por mercancas o servicios suministrados, tal como el valores que una compaia obtiene de ventas con los gastos relacionados con los elementos cuyo valores se transfiere fuera de la compaa. Como resultado este mtodo muestra la informacin de P&G en una forma til para obtener anlisis de mrgenes y por tanto es ptimo para ventas, marketing y reas de gestin de producto. Period Accounting: Con este mtodo se hace nfasis en suma de la actividad y situacin de cambio en un periodo de tiempo dado para una unidad organizativa. Como resultado, presenta los ingresos y gastos primarios que se han incurrido para un periodo de tiempo y los cambios en los niveles de valores de stock, wip y actividades capitalizadas. As, es adecuado para areas de produccin y cebes. CO-PA permite analizar la rentabilidad de segmentos especficos de mercado estructurados de acuerdo a productos, clientes, o suma de estos y otras caractersticas. El objetivo de proveer a las reas de ventas, marketing y gestin de productos con informacin de control orientada al mercado para ayudar a la toma de decisiones. La definicin tanto del mercado como de los ratios (performance key figures) on ampliamente definibles, permitiendo la mxima flexibilidad. Esta definicin de un mercado se configura mendiante un nmero de caractersticas sujetas a anlisis. Los ratios pueden ser tanto cuentas de P&G como campos valor definibles EC-PCA se puede usar para analizar las perdidas y ganancias por cebes. Esto permite evaluar las diferentes reas o unidades dentro de la compaa. Puedes estructuras los cebes de acuerdo a regiones, funciones o productos. Es un componente de Enterprise Controlling. EC-PCA permite calcular resultados internos por cebes. Todas las transacciones relevantes a gastos o beneficios en SAP son actualizadas en el cebe. Esto transforma el flujo de mercancas y servicios dentro de la compaa en un intercambio entre cebes. El mtodo para determinar el resultado de las operaciones periodicas en PA est basado en la presuncin de que el xito de la compaa se puede medir en la base de sus transacciones con otras compaas. El objetivo es suministrar a ventas, marketing, gestin de productos, controlling y al equipo de planificacin corporativa con informacin para la toma de decisiones. Este enfoque orientado a ventas en COPA significa que no hay contribucin al exito hasta que la venta se ha completado. Como resultado, los productos vendidos se transfieren a PA de acerudo con el cost-of-sales method y provee informacin sobre los ingresos y deducciones por venta.

Las imputaciones reales son la mayor fuente de informacin en PA. Se puede transferir tanto pedidos y facturas desde SD a PA. Tambin se puede transferir los costes de cecos, ordenes y proyectos, adems de costes e ingresos desde imputaciones directas a cuentas de mayor o por liquidacin de costes en CO a objetos PA.

STRUCTURES
Las caractersticas identifican la dimensin de anlisis en PA. Determinan que elemento u objeto se puede evaluar. Varias caractersticas, tal como Org. de Ventas, cliente y producto estn predefinidas automticamente para cada SocPA. Se conocen como caractersticas fijas. Adems, se pueden aadir hasta 50 caractersticas no fijas a una SocPA. Las caractersticas no fijas deben aadirse al catlogo de campos antes que puedan usarse para definir la SocPA. En el catlogo de campos sern accesibles en cualquier mandante. El catlogo de campos originalmente contiene las caractersticas por defecto que son usadas para definir la SocPA. Hay dos formas de aadir otras caractersticas al catlogo: 1 desde ciertas tablas SAP, escogiendo un campo existente que tenga 5 caracteres o menos 2 crear la caracterstica independientemente, empezando con WW y con 4 5 caracteres en total. Cada caracterstica potencialmente tiene una tabla de verificacin para sus valores de caractersitca. Esto valida el dato introducido en COPA. Si creas una nueva caracterstica en el catlogo, puedes decidir si el sistema debe generar una tabla de verificacin. Las caractersticas se pueden categorizar de acuerdo a como y cuando se han definido: 1 copiandolas con referencia a una tabla. Puedes usar caractersticas que ya existen en otras aplicaciones cuando defines la SocPA. 2 caractersticas nuevas. Puedes crear caractersticas que se requieran slo en PA. Para derivar los valores para estas caractersticas se precisa definir su estrategia de derivacin 3 caractersticas predefinidas. Adems de las finas, un nmero de otras caractersticas predefinidas estn disponibles en el catlogo de campos para copiarlas en la SocPA. (grupo de clientes, pais,...) 4 caractersticas fijas. Un nmero de caractersticas bsicas estn automticamente predefinidas en cada SocPA (nmero de producto, clase de factura, SocFi, business area y pedido) En PA analtico, los campos valor guardan las cantidades o importes para reporting. Los campos valor pueden estar sumarizadas (varias clases de coste) o detalladas (slo una clase de coste). Al contrario que las caractersticas, no hay campos valor fijos. Todos los campos valor deben existir en el catlogo de campos antes que se puedan usar para definir la SocPA. Estos campos valor son accesibles desde cualquier mandante. En el catlogo se sugieren algunos campos valor (revenues, COGS, Sales quantity). Los campos valor pueden definirse independientemente empezando por VV y con 4 5 caracteres. No se necesitan crear campos valor para calcular elementos. Estos valores usualmente se calculan durante la ejecucin de informes. Esto minimiza los requerimientos de memoria. Ratios bsicos fijos (fixed basic key figures). En PA contable todos los valores se actualizan en cuentas. Cada cantidad se guarda en hasta 3 monedas diferentes bajo ratios bsicos fijos que a los que se acceden en reporting.

Definiendo los atributos de la SocPA: 1 Crear caractersticas 2 Crear campos valor 3 Crear la SocPA Cuando defines la estructura de la SocPA, seleccionas las caractersitcas que quieres usar. En PA analtico, tambin necesitas seleccionar los campos valor. La estructura de la SocPA es vlida en todos los mandantes. Los atributos de la SocPA son parmetros especficos de mandante. Definicin de la estructura de datos: Definir la estructura de datos, copiar las caractersitcas y campos valor requeridos para la SocPA y guardar. Activar el entorno (hasta 4.6B): Despus de definir los atributos de la estructura de datos se debe activar y generar el entorno. Este proceso crea todas las tablas, programas y objetos tcnicos requeridos. Despus de generar la SocPA y antes de activar PA para la entrada de datos, aadir los valores de caractersitcas vlidos a las tablas de verifiacin de las nuevas caractersitcas. Se debe reactivar el entorno despus de cambiar la estructura de datos de una SocPA (aadir caracterstica o campos valor). La regeneracin no afecta a datos transaccionales ni a valores de caractersticas existentes. PA analtico tiene sus propias tablas que se crean durante la activacin y generacin de la SocPA. Esto significa que sus datos nunca afectar a la velocidad de ejecucin de otras aplicaciones CO. PA contable guarda sus datos en tablas de CO-OM. Esto significa que sus datos afectarn a la velocidad de ejecucin de informes de CO que compartes dichas tablas: PA analtico: 1 CE1XXXX 2 CE2XXXX 3 CE3XXXX 4 CE4XXXX partidas individuales reales partidas indivuduales plan registro de totales por segmento definicin de segmento

PA Contable 1 COEP partidas individuales reales 2 COEJ partidas individuales plan 3 COSS/COSP registro de totales (operaciones internas/externas) 4 CE4XXXX definicin de segmento. El segmento u objeto PA que representa el objeto de asignacin de costes en PA, es la combinacin nica de valores caractersticas que el sistema crea y numera automticamente desde la informacin de la transaccin originaria. Por razones de rendimiento es aconsejable mantener el nmero de segmentos y as de registros de totales a un mnimo. Esto se puede controlar limitando la seleccin de caractersticas para el segmento. El sistema se configura para que ciertas caractersticas no sean usadas en la definicin del segmento. Los valores de estas caractersticas (non-segment-level), aparecern en los informes de partidas individuales, pero no estarn disponibles en la herramienta de drilldown reporting. Se puede parametrizar para cada caracterstica si se usar a nivel de segmento y hacer diferencia entre PA analtico o contable. En general ciertas caractersticas fijas no se usan a nivel de segmento, aunque esto se puede modificar.

SAP recomienda que en PA contable los datos se sumaricen a un nivel ms alto que a nivel de cliente o producto para minimizar el nmero de registros de totales. Esto es porque los datos compartes tablas con CO-OM.

MASTER DATA
Algunos puntos clave sobre la derivacin: 1 suplementa o sobrescribe ciertos mapeos automticos de valores caractersticas 2 la estrategia de derivacin es una secuencia de pasos donde cada paso usa una tcnica de derivacin para calcular una o ms valores para una o ms caractersticas 3 Se puede asignar atributos de control a cada paso, tal como condiciones para su ejecucin, permiso para sobrescritura, comportamiento ante el fracaso del paso,.. 4 Algunos pasos se crean automticamente en tiempo de generacin y pueden ser modificados. Otros los creamos. Puntos claves de la valoracin: 1 Suplementa a los datos que pasan directamente de otras apliaciones con clculos,.. 2 una estrategia de valoracin puede contener CO-PA costing sheets, procedimientos de pricing de SD, product costing estimates o llamadas a exits. 3 una estrategia de valoracin debe asignarse a una clase de registros, punto de valoracin y versin plan. 4 su uso es opcional. Es una herramienta que puede usarse como intento de obtener la mas completa y til informacin de COPA. Cada dato introducido en COPA se determina por la asignacin automtica o manual adems de por la configuracin de la derivacin y la valoracin. (el cliente y el producto no se puedes sobrescribir con derivacin). Para cada transaccin relevante a PA, si la estrategia de derivacin est completa, el sistema intenta derivar el valor de la caracterstica para cada caracterstica de la SocPA. La derivacin no siempre tiene xito. Si el sistema no puede determinar un valor, entonces deja la caracterstica en blanco o desasignada. El total de todos los valores de caractersticas usadas a nivel de segmento define el segmento u objeto PA. Cada paso de la estrategia de derivacin define la interrelacin lgica entre la caracterstica fuente y la caracterstica a derivar. El sistema crea automticamente una estrategia de derivacin estndar para cada SocPA. Esta estrategia contiene los pasos de derivacin para todas las dependencias que ya se conocen. Se puede cambiar esta estrategia de acuerdo a nuestros requerimientos. Los paso de la estrategia de derivacin se realizan en una secuencia parametrizable para maximizar la posibilidad de localizar o determinar el valor. Los siguientes elementos se pueden configurar para cada paso: 1 condiciones bajo las que el paso se debe ejecutar 2 si el valor vaco est permitido en el campo fuente 3 si el paso debera sobrescribir un valor existente

si debe aparecer un mensaje de error si el paso no tiene xito

Cada paso representa normalmente una de las parametrizables tcnicas de derivacin: 1 table lookups 2 reglas de derivacin 3 jerarqua de producto o clientes 4 moves, clear (asignacin y inicializacin) 5 exits Ciertas caractersitcas como divisin y cebe tienen pasos de derivacin fijos. Esto significa que el sistema genera automticamente pasos no modificables para determinar su valor. Se pueden usar otros pasos para sobrescribir los valores determinados por los pasos fijos. Esto normalmente se lleva a cabo para todas las caractersticas excepto SocCO, SocFI, producto y cliente. Estos tienen derivacin fija no modificable. A alto nivel, los pasos fijos de derivacin aseguran la reconciliacin con otros componentes SAP o al menos mejora estos a otros niveles. Los table lookup son mtodos usados en PA para acceder a valores caractersticas de tablas maestras si esta informacin no est en la transaccin original. Se lleva a cabo cuando la clave de la table puede obtenerse de los valores caracterstica ya conocidos. La regla de derivacin se usa para determinar el valor a travs de una lgica definible por el usuario. El valor se determina directamente en base a los valores de caractersticas fuente conocidas. Al contrario que otros paso de derivacin, la regla de derivacin se puede definir como time-dependent o time-independent. Se pueden establecer en secuencia con otros pasos y mtodos para producir una lgica de derivacin compleja. El sistema automticamente genera un paso de derivacin de tipo asignacin (move) al cebe dummy si no se ha determinado el cebe en otros pasos de derivacin. En PA analtico se puede configurar una funcin conocida como valoracin que suplementa la informacin suministrada directamente por una transaccin. La informacin adicional puede ser estimada, calculado o retribuida de diferentes fuentes. Por ejemplo, se puede configurar el sistema para que automticamente calcule comisiones por venta con cada transaccin cuando se transfiera la factura a PA. Esto permite estimar el resultado de la transaccion sin necesidad de imputar todos los datos reales. Se usa tanto para datos plan como reales. Se usa a menudo para acceder a la determinacin del precio y la informacin del coste del producto que tienen cantidades planificadas. La valoracin se puede configurar tanto en tiempo real (en el momento del apunte) o periodicamente. La valoracin periodica tiene la ventaja de reducir la carga del sistema. La estrategia de valoracin es central en la configuracin de la valoracin. Puede contener referencia a multiples tcnicas de valoracin como: 1 costing sheet (esquema de clculo del coste), las clases de condicin se mapean a campos valor 2 exits. los campos valor se actualizan directamente 3 informacin de product costing. con material cost estimates, los cost component se mapean a campos valor Usando la clase de registro A, B, C, F y 0-9 (user-defined) decides que estrategia quieres usar en qu momento. Si la estratega aplica a datos plan, hay que especificar la versin plan.

CO-PC se usa para generar estimaciones del coste de materiales. El resultado de la estimacin puede visualizarse de diferentes maneras, por partida, por clase de coste o por componente del coste. A travs de la valoracin, la iformacin del product cost estimate se puede transferir a CO-PA mediante los valores del componente del coste. En la IMG los cost component se mapean a los campos valor. Se puede mapear cada componente del coste a su propio campo valor o multiples componentes a campos valor individuales. Tambin se puede mapear porciones fijas o variables en campos valor separados. Usando la costing key (seleccin del clculo del coste), puedes determinar que cost estimate se debe usar en que fecha de validez. Asignando una costing key, controlas que cost estimate, estandar, estandar modificado o cost estimate actual se debe usar en que caso dependiendo del material, clase de material o cualquier otra combinacin de caractersticas. Si existe una entrada para el material, tiene prioridad sobre la clase de material y la clase de material sobre cualquier otra entrada definida para otras caractersticas. En la assignment lines determinas que valores del cost component structure se transfieren a que campos valor. Cuando se define la costing key, puedes introducir tanto un costing date, un periodo o un valor para el period indicator. Usando el plan period indicator, especificas para que el sistea debera buscar para un material cost estimate valido in la base de datos de CO-PC. Opciones disponibles: 1 0. para la future estandar cost estimate (valido el primer da del periodo) 2 1 para la current (valido el primer da del periodo) 3 2 para la past (valido el primer da del periodo) 4 3 para la estandar valida en el posting date 5 4 para la estandar valida en el dia de la goods issue Adems de asignar la costing key a la clase de producto o material, tambin se puede asignar a cualquier combinacin de caractersticas, lo que da una gran flexibilidad y control en el uso de costing keys. Se pueden usar hasta tres caractersticas como campos fuente, como centro, producto y grupo. La costing sheet permite el acceso o calculo de valores especiales. Son centrales en la tecnica de condiciones. Consiste en una secuencia de clases de condicin definidas por el usuario que acceden a un valor o realizan un calculo especifico dictado por la clase de condicin. Cada clase de condicin se mapea a un campo valor. La clase de condicin representa un paso en la costing sheet. El clculo que el sistema realiza en este paso depende de: 1 condition category 2 tipo de calculo (determina como el sistema calcula precios, descuentos o recargos para una clase de condicin) 3 condition class 4 escala base La funcin de analisis de campos valor permite analizar todo el flujo de datos reales a PA. El informe muestra en que flujo de valores el campo valor interviene y que clase de condicin o clase de coste lo datermina. Se puede analizar: 1 transferenca desde billing o incoming sales orden de SD 2 imputaciones directas de FI 3 liquidacin de ordenes y proyectos desde CO-OM o subrepartos

transferencia externa.

ACTUAL DATA
Fuentes tipos de orgenes de campos valor: 1 clases de condicin (billing) 2 cost component, (cost estimates) 3 clases de coste (FI, CO-OM, PS, ordenes de produccin) 4 varianzas (ordenes de produccin) La integracin con SD juega un papel central en PA. En particular, notar la diferencia entre PA analtica y contable. El principal propsito de PA analtica es proveer a gestin de ventas con una herramienta para el analisis del resultado esperado de la actividad comercial. Su principal caractersitca es el uso de campos valor y el calculo automtico de la valoracin. La ventaja es que los datos es "up-to-the-minute" PA contable permite reconciliar costes y FI en cualquier momento a nivel de cuenta. En contraste con PA analtico, el sistema guarda valores en clases de coste de gasto o ingreso que forman la estructura comun para todas las aplicaciones FI. Todos los costes o ingresos se imputan simultaneamente a PA y usa el mismo enfoque de valoracin que FI. La principal diferencia aqui es que el metodo de costes de ventas se transfiere en el momento de la salida de mercancas y no con el ingreso. Se puede evaluar los pedidos entrantes como ingresos esperados y transferirlos a PA analtico desde SD para obtener un anlisis anticipado de los beneficios. Como resultado, puedes crear informes que no slo reflejen el curso de los beneficios reales y la contribucin al margen en base a la facturacin, sino tambin analizar el desarrollo en base a pedidos entrantes. Para analizarlos se usa la clase de registro "A" (para billing "F") Hay dos opciones para activar la transferencia de pedidos entrantes: 1 activarlo por fecha de entrada (actualiza el pedido en el mismo periodo en que fue creado) 2 transferir con fecha de entrega/facturacin planificada (muestra el pedido en PA en el periodo que se planific la entrega o la facturacin y por consiguiente proporciona una visin ms prxima de los pedidos entrantes) La salida de mercancas se dispara con la entrega en SD. Esto afecta en MM y FI al imputar existencias contra variacin de existencias (esto no afecta a PA contable, se tranfiere a PA contable con el billing document). Cuando la factura se crea, en SD se calculan los ingresos, descuentos y otros valores como el coste estandar usando la determinacin del precio (pricing) y guarda todos los valores en clases de condicin. Asignando estas clases de condicin a campos valor en PA, se puede tener la transferencia automatica a PA. Durante la facturacin, el sistema valida que FI y PA sean actualizaos. Si uno de los apuntes no se puede llevar a cabo por error, el sistema no contabiliza. Esto asegura la actualizacin en paralelo y la reconciliacin entre PA y FI. Durante el procedimiento de determinacin del precio, se define las condiciones que estn permitidas para un documento en particular y la secuencia en que el sistema toma estas condiciones en cuenta. Adems, se asigna el procedimiento de determinacin del precio a las transacciones mediante la definicin de las siguientes dependencias: cliente, clase de pedido o area de ventas. La clase de condicin es una representacin de algn aspecto

involucrado en la asignacin de precio. Una tabla de condiciones define la combinacin de campos que identifican un registro de condicin en particular. Una secuencia de accesos es una estrategia de busqueda que el sistema usa para encontrar datos validos para una clase de condicin en particular, establece que registros de condicin tienen preferencia sobre otros. Se especifica una secuencia de acceso para clase de condicin para la que se crean registros de condiciones. La clase de condicin VPRS transfiere a PA los costes de venta que fueron imputados en el momento de la salida de mercacas. Incluso si el precio estandar ha cambiado entre el momento de la SM y el momento de la facturacin, VPRS guarda este valor y asegura que el coste de ventas est reconciliado con FI. En PA contable, los costes se liquidan bajo la clase de coste de liquidacin especificada en el esquema de imputacin. En PA analtica los costes se liquidan desde la clase de coste original al campo valor especificado en el PA transfer estructure (esquema PAFI). El esquema PAFI contiene la asignacin de las clases de coste de gasto o ingreso a los campos valores en PA analtico. Se usa para liquidacin de rdenes, imputaciones directas de FI y facturacin de actividad en CO-OM. El esquema PAFI debe cumplir lo siguiente: 1 debe estar completo. todas las clases de coste de gasto o ingreso deben estar en el 2 la asignacin debe ser nica. Se asignan valores al objeto PA en FI directamente durante la contabilizacin, llamando al bloque de imputacin a PA. En este bloque se puede escoger caractersticas definidas. Para definir la estructura del bloque, se crean grupos de caractersticas para la actividad RFBU en la IMG. El grupo de caractersticas define que caractersitcas se mostrarn. Para las imputaciones de FI, toda la asignacin de valores y cantidades en PA analtico est definido en el esquema PAFI. En PA contable los datos se contabilizan sobre la misma clase de coste de gastos o ingreso. Si se permite la imputacin tanto a PA como a ceco, la imputacin real siempre va al objeto PA, el ceco ser estadstico. Las contabilizaciones automticas, como las generadas en MM, se pueden transferira PA usando la funcion de asignacin automtica a PA. El documento se actualiza en PA para el segmento encontrado en base a las caractersticas del documento FI correspondiente

TFIN22_2B
REPORT PAINTER
La interfaz de usuario del Report Painter se puede usar para varios propsitos:

1 2

Planning Layouts; Drilldown reports;

Report writer reports

Representa la interfaz entre el usuario y Report writer. Usa una estructura de reporte grfica que forma la base de definicin del informe y muestra las filas y columnas del informe como aparecer tras la compilacin. Componentes: Report group, Report and library ---- Customer Reporting table ----- SAP DB tables SAP La library contiene: characteristics, basic key figures, key figures and reports with related content Definicin del informe: determinamos filas, columnas y general data selection Podemos decider salvar un extract (foto de un informe en un momento dado) y el tiempo requerido para mostrar el informe disminuye considerablemente pues se accede al extract no a la DB.

DRILLDOWN REPORT
Proporciona una herramienta de reporting en lnea para evaluar los datos de PA. Pueden mostrar tanto informes con un simple fixed layout (basic report) o con estructura compleja y formato (form reports) Las funciones drilldown se dividen en tres grupos que difieren en la cantidad de opciones disponibles. Se usa tanto en consting-based como en account-based. Output types: - Convencional Hotspot navig. Printing option, Office integration - Graphical Variable output areas, HTML header, drag and drop - Object List (SAP list viewer) Differents lead columns, Standard function en el SAP list Tres niveles de funciones: - Level 1: basic functions + email - Level 2: rest of functions + excel + charts - Level 3: todas + print, saving y definer excepciones El nivel individual est sujeto a un authorization check Tipos de excepciones (regla que define si el rendimiento de un prof. segment difiere de lo esperado): - Single cell - Drilldown list Tipos de form reports: - One axis without key figure - One axis with key figure - Two axis with key figure

Para crear un form report introducimos nombre y tipo.

SAP BW REPORTING
Queries: - excel-based (Bex) - Web-based BW organiza la informacin de Fuentes diferentes y heterogneas. Usa una arquitectura multinivel. Los infobjetos son los objetos de anlisis (infocubos, infoproviders) que son divididos en characteristics (describen la asignacin de key figures) y key figures ( data fields donde se salvan valores o cantidades). Podemos salvar una version de una query en un workbook de excel. El Query Designer tiene 6 areas (screen areas): - directory tree del infoprovider - definicin de columnas - definicin de filas - user-defined characteristics - filters - preview de la query Dos opciones para cambiar una query: - change query (local view) save or save as - change query (global view) save or save as