Contabilizaciones con tipo de valor estadístico

[bisonye]

Hola,

Tengo un problema con los traspasos a CO y PA. Resulta que en ciertas órdenes de CO queremos que la liquidación de la orden pase tanto a PA como a centro de coste. He conseguido realizarlo pero la contabilización en el centro de coste pasa con el tipo de valor '11' (real estadístico) y quiero que pase a tipo de valor '04' (Real)
Por lo que he visto este es el comportamiento estándar del sistema, pero me interesa que sea de la otra forma.

¿Alguna forma de hacerlo?

Gracias.

[eugevi]

Valores Reales y Valores estadísticos

Hola.

Lo primero que me llama la atención es ¿Porqué quieren duplicar los valores dentro de la contabilidad de controlling?
Te paso lo que me viene a la cabeza, como razonamientos/comentarios. Quizas te ayuden.

Solo puedes pasar un valor como real a un único objeto de CO. En este caso, el ceco es el único objeto que en si mismo, sin que le tengas que indicar algo mediante un flag, que en forma automática si hay otro objeto que es real, se vuelve estadístico.
Adicionalmente, si el valor es un ingreso, para SAP es el objeto real es el PA.Y el objeto estadístico es el ceco..
Por otra parte, sigo sumando temas, perdona. Es correcto también a nivel proceso, el valor, en forma "real" solo debe pasar a un objeto, sino estarías incurriendo en una doble imputación.
O es de A o es de B, en alguno de los dos, deberá ser algo solo informativo, y por ende, solo lo verás en algunos reportes (en la parte estadística), y , en el caso de cecos, no podrás realizar operaciones (ej. distribuciones). Solo un área / sector /negocio / venta, se hace responsable de eso, el otro es, como decir, bueno, yo también participé, pero "no me hago cargo".

En el caso de las OI, tienes que decirles si van a ser reales o estadísticas. (sea porque le marcas flag al crearlas, o armas su clase de orden para que nazcan estadísticas de una). En este caso, cuando juegan con un ceco, manda la orden. Si la orden es real, ceco se convierte en estadistico. Si la orden es estadística (ej, porque quieres usarla para controlar presupuesto, algo que te permite hacer una orden estadística al igual que una rea, o por ejemplo, usas eso, porque quieres representar alguna idea, ej. una temporada, etc.l), el ceco sera real.

¿Qué objeto es algo particular en este caso? El CEBE, que siempre es estadístico, aunque sobre el, sobre todo en versiones ECC 5 con NGL activo, tienes opciones de realizar varios tipos de operaciones. ¿Porqué es estadistico para SAP? porque, en general, el CEBE se desprende de otros objetos (deriva su valor en los registros de otro objeto), y lleva tanto ingresos. Con ECC, puedes tener imputaciones en donde no haya solo un cebe..cuando lo estás usando con la idea de segmentación, funcionalidades de desglose, etc, por ende en cuentas de gl, según armes el modelo, puede haber un cebe, pero en su esencia, sigue siendo un objeto estadistico.

Por lo cual, si vuelvo a tu pregunta. O lo imputo en a o en b, como real. O estoy analizando algo mal, es una parte en A, y otra parte en B. O estoy usando los objetos que no correspondería para el concepto que se quiere representar. ...

Ojalá te ayude. Saludos, Eugevi.

Hola,

Tengo un problema con los traspasos a CO y PA. Resulta que en ciertas órdenes de CO queremos que la liquidación de la orden pase tanto a PA como a centro de coste. He conseguido realizarlo pero la contabilización en el centro de coste pasa con el tipo de valor '11' (real estadístico) y quiero que pase a tipo de valor '04' (Real)
Por lo que he visto este es el comportamiento estándar del sistema, pero me interesa que sea de la otra forma.

¿Alguna forma de hacerlo?

Gracias.

[bisonye]

Buen tocho, si señor, muchas gracias primero.

Ahora como veo que entiendes mucho lo que estamos hablando te comento con más detalle las necesidades.

Tenemos una serie de gastos de comerciales que imputamos en ordenes CO. Estas órdenes, hasta no hace mucho, al liquidarlas se traspasaban a un ceco. Hasta ahí todo correcto.

Desde hace unos meses se quiere estudiar las rentabilidades analíticas de las ventas y para esto estudiamos las ventas, el coste y los gastos en que se incurren. (Desplazamientos, alquileres, dietas...) Las ventas vienen de SD e imputan directamente en PA. Los gastos pueden venir de dos sitios, el primero son contabilizaciones directas que van contra ceco, esto son gastos en los que los comerciales no están implicados. Estos gastos mediante subrepartos los pasamos mensualmente a PA para asignarles una oficina de ventas y poder analizarlos junto con las ventas. Aqui mi primera pregunta, ¿no estamos duplicando la impùtación ya?
La segunda imputación de gastos son las ódenes de comerciales. Las contabilizaciones de gastos en las que si están implicados los comerciales se contabilizan contra una orden. Para poder asignar esto a una oficina de ventas se cambio la liquidación para que fuese a PA pero el contable dice que lo necesita también en cecos y que para el es un tema diferente.

No se si me he explicado pero después de tu explicación tengo dudas. ¿No está bien desarrollado? (esta funcionalidad no la puse yo, la he heredado y empiezo ahora a tratar costes, con lo que soy bastante ignorante al respecto) ¿Por que no podemos hacer una doble imputación si los análisis los hacemos por separado? ¿Los subrepartos de cecos a PA no están haciendo una doble imputación también?

Muchas gracias y perdona el tocho.

Saludos.

[eugevi]

Vuelvo en parte a los conceptos

Sigue siendo un tema el qué quieren. Es decir, entender para qué tipo de anàlisis u operación es que lo requieren como real en CO. A ver, en general, el Ceco, la idea es que tengas una estructura que represente en lo posible el apropiador final de costo. Ok, puedes tener estructuras donde usan cecos genéricos, pero luego en general, se la pasan haciendo distribuciones y subrepartos..lo cual dista de lo óptimo o recomendable de buena práctica. Por otro lado, la OI, en general representa algo que es un conjunto de imputaciones, puede incluir ingresos, y terminar distribuyendo un saldo, tienes objetos adicionales como destinatarios que un Ceco no (ej. un activo), e incluso, si quieres que alguien no pueda imputar, la orden es el primer objeto que te permite, trabar una operación. Aunque no puedes trabajar con valestadísticoss ni actividades, como verás cada objeto tiene sus pros y contras. En el DM de una orden tienes para colocar una referencia al pedido de venta.. en un ceco..no. . En ambos tienes la posibilidad de estar trabajando de la mano de un CEBE. Desde luego, se pueden analizar diferentes estructuras, u objetos que pudieran dar la información. El pedido de venta también alimenta PA según tenga configurado, y quizás los valores los pueda explotar con user exits - para logicas más complejas - , para llegar a los valores en los campos valor. Reitero, es importante que sepas porqué no les sirve la informaciòn estadìstica, si acaso no estan mandando algo a PA que no deberìa ir, y ese es el detalle, que tengan que eplotar mejor el equema de imputaciòn, y quizas la liquidaciòn hacerla hacia Pa deteminados valores, y Cecos otros valores de los que están en las ordenes. Desde luego, puede haber un tema de estructura. Tu dices que precisan analizar la información por oficina de ventas, ahora, los costos y rentabilidad son por producto o por oficina de ventas? Ten en cuenta, que por ejemplo el Cebe va de la mano de Cecos /Ordenes (o dicho de otra forma 1 cebe puede agrupar conceptualmente a varios cecos /oi. Y a su vez s/versión sap, tienes los segmentos, donde 1 segmento puede agrupar conceptualemnte a varios Cebes.. Y no nos olvidemos de las áreas funcionales. Son todos objetos que permiten cruces de información. Pero eso es análisis muy particular. Es consultoria pura. Ya no es una respuesta general. Y sin conocer modelo o no hacer consultoria, decirte qué esta bien o mal, sería incorrecto. ¿Se entiende? .

Si puedo, como se me ocurrió, al momento de responder, es tratar de alinear conceptos, independientemente del modelo. Y aqui el ultimo aporte. Ojo con las operaciones en CO. ¿A qué me refiero? pues.

Tu grupo 1. Son losclásicoss Gastos Generales, que se apropian a la venta, pero que no tienen que ver con la venta en forma directa. Hasta ahi Ok. (Ej. es eltípicoo ejemplo de comedor, que tienes un conjunto de gastos asociados. pero no repartes cada gasto, los sumas a todos y luego dice, de este total de gasto de comedor, a ti te corresponde tanto).
Qué hace un subreparto? no duplica nada. vacía de un lado y completa en el otro. El tema es mediante qué lo hace. En el subreparto pierdes la trazabilidad de la clase primaria, y la idea es que esa es su idea!. Y lo usas porque justamente, vas a subrepartir según un concepto particular. (no por el origen del gasto).
Ej. Sumas Gasto A (clase primaria 4040) + Gasto B (clase primaria 4041) da un total X. Y ese valor, luego bajo algún criterio (%,monto fijo, partes iguales, valore estadísticos, actividades, etc), lo que interesa es el concepto que reparto, comedor.Y ese concepto lo representa la clase de costo secundaria que es la que hace los créditos / débitos respectivamente.
La clase de costo secundaria baja los valores en los orígenes, y lo aumenta en el destino, por ende, no duplicas, sino que "reclasificas".

Hasta aquí puedo llegar. Y tranquilo. Insisto, fijate bien qué es lo que quiere ver el usuario, y tu mediante ejemplos, muéstrale lo que podrá ver, aunque sea un valor estadístico. Baja a los ejemplos, eso es lo que más te va a ayudar a entender si algo lo estan metiendo en donde no deben, y si quizas es solo un tema de apertura. Saludos, Eugevi

Hola.

Lo primero que me llama la atención es ¿Porqué quieren duplicar los valores dentro de la contabilidad de controlling?
Te paso lo que me viene a la cabeza, como razonamientos/comentarios. Quizas te ayuden.

Solo puedes pasar un valor como real a un único objeto de CO. En este caso, el ceco es el único objeto que en si mismo, sin que le tengas que indicar algo mediante un flag, que en forma automática si hay otro objeto que es real, se vuelve estadístico.
Adicionalmente, si el valor es un ingreso, para SAP es el objeto real es el PA.Y el objeto estadístico es el ceco..
Por otra parte, sigo sumando temas, perdona. Es correcto también a nivel proceso, el valor, en forma "real" solo debe pasar a un objeto, sino estarías incurriendo en una doble imputación.
O es de A o es de B, en alguno de los dos, deberá ser algo solo informativo, y por ende, solo lo verás en algunos reportes (en la parte estadística), y , en el caso de cecos, no podrás realizar operaciones (ej. distribuciones). Solo un área / sector /negocio / venta, se hace responsable de eso, el otro es, como decir, bueno, yo también participé, pero "no me hago cargo".

En el caso de las OI, tienes que decirles si van a ser reales o estadísticas. (sea porque le marcas flag al crearlas, o armas su clase de orden para que nazcan estadísticas de una). En este caso, cuando juegan con un ceco, manda la orden. Si la orden es real, ceco se convierte en estadistico. Si la orden es estadística (ej, porque quieres usarla para controlar presupuesto, algo que te permite hacer una orden estadística al igual que una rea, o por ejemplo, usas eso, porque quieres representar alguna idea, ej. una temporada, etc.l), el ceco sera real.

¿Qué objeto es algo particular en este caso? El CEBE, que siempre es estadístico, aunque sobre el, sobre todo en versiones ECC 5 con NGL activo, tienes opciones de realizar varios tipos de operaciones. ¿Porqué es estadistico para SAP? porque, en general, el CEBE se desprende de otros objetos (deriva su valor en los registros de otro objeto), y lleva tanto ingresos. Con ECC, puedes tener imputaciones en donde no haya solo un cebe..cuando lo estás usando con la idea de segmentación, funcionalidades de desglose, etc, por ende en cuentas de gl, según armes el modelo, puede haber un cebe, pero en su esencia, sigue siendo un objeto estadistico.

Por lo cual, si vuelvo a tu pregunta. O lo imputo en a o en b, como real. O estoy analizando algo mal, es una parte en A, y otra parte en B. O estoy usando los objetos que no correspondería para el concepto que se quiere representar. ...

Ojalá te ayude. Saludos, Eugevi.

[bisonye]

eugevi me has aclarado muchos conceptos que desconocía.

Sólo puedo darte las gracias y dedicarme a analizar los requerimientos de nuevo con los usuarios y seguramente, como dices, asistencia de consultoría.

Ya veo que es un tema mucho más complejo de lo que pensaba en un principio.

Muchas gracias.