CO-PC Cuadre cecos cierre de mes

[oscar_dc]

Hola Sidv, muchas gracias por tu respuesta.

En realidad, la diferencia en el cuadre de los centros de costos productivos y de servicio siempre quedo así desde el inicio de SAP, pero era una diferencia muy pequeña, hablamos de unos usd$2, entonces lo que quisieron fue poder ajustarlos.

Ahora bien revisando esto, realice un ejercicio que me arroja este resultado:Para poder ajustar la diferencia a una cuenta de redondeo, se ejecuta un ciclo de subreparto a final de mes despues de todo el cierre de costos, cuando tengo la diferencia en dólares me ajusta esos usd$2, ahora bien, cuando reviso la contabilización enviada a la cuenta de redondeo tengo el ajuste por usd$2 y por ML de 10.000.000 . Entonces que sucede, tome todos los registros del mes y los valore al tipo de cambio del momento que se ejecuto el ciclo de subreparto, resulto ser que la suma de la diferencia entre cada contabilización y el ajuste al tipo de cambio, me da precisamente 9.972.000, si tomo esto y le resto los 10.000.000, y lo convierto a dolares, me da precisamente usd$2 , o sea, según yo solamente no ajusta los usd$2 que quería ajustar, pero si todo lo demás.

Nunca habia manejado una CO en dólares, pero según el ejercicio anterior me hace creer, que cuando ejecuto los ciclos de subreparto, para pasar las contabilizaciones de USD a ML, lo que hace es ajustar todas las contabilizaciones con el tipo de cambio del momento, y por supuesto generar estas diferencias tan grandes.

Ahora bien, como se menciona en la respuesta anterior, si la sociedad CO es en dolares los reportes se deberian ver en dolares, pero como les he comentado, hasta el momento nadie me ha sabido dar una respuesta de porque lo hicieron así, y de hecho a nadie le sirve que así sea.

En fin, ahora alguien me puede confirmar si esta teoria que formule esta muy disparatada? se actualizan los registros de los ciclos al TC del momento?

Saludos a todos.

[ricardoahm]

Hola Oscar,

A mi se me presentó una situación similar, luego de varias pruebas llegué a la conclusión de que el problema estaba en la determinación de tarifas reales, Como la moneda de la sociedad CO es el dólar, las tarifas de las actividades también están en dicha moneda, sin embargo, la tarifa en moneda local ML se determina por conversión, al realizare los cargos y abonos de los costos en distintas fechas los tipos de cambio varían de modo que el importe en ML suele no abonarse por completo, mientras que los importes en dólares si, te sugiero que revises lo sgte.

- En la planificación de actividades (KP26), incrementar el valor de la unidad de tarifa, lógicamente el valor de la tarifa también, esto permitirá mayor exactitud en la determinación de tarifas reales,

- Cuando determines la tarifa real (KSII), activa la opción "Importes iterativos independientes", esto permitirá que las tarifas se determinen independientemente en dólares y moneda ML abonando los importes completamente, así mismo, incrementa el valor del parámetro: "N° Pos.Significantes" a 10 por ejemplo.

espero te ayude,

Ricardo.

[oscar_dc]

Hola Ricardo, muchas gracias por tu respuesta.

En realidad el error que tenia sobre la orden de redondeo, lo analice y efectivamente, lo que sucede es que cuando se ejecuta el ciclo de subreparto para enviar las diferencias a la cuenta de "redondeo", lo que hace el ciclo es que envia un equivalente de todas las partidas que se registraron en esas cuentas al tipo de cambio del momento que se ejecuta el ciclo, entonces al final en dólares solo tengo una diferencia pequeña, pero en ML me queda el exedente total de toda la revalorización realizada y no la correspondiente a esa pequeña diferencia, o sea, como dices, al estar la moneda de la sociedad CO en dólares todas los procesos que se hagan a partir de este módulo quedarán efectivamente en dólares a un tipo de cambio determinado.

Con respecto a tu consejo voy a revisarlo, me parece que tiene mucha lógica por estar la sociedad en $USD, para el primer punto pues la unidad de tarifa esta en 1000, voy a proponer que suban todas a 10000, o que hagan la conversión hasta la unidad más alta que se pueda (creo que sería 10.000) en este caso.
El caso de la KSII, la verdad nunca he visto esto que comentas, voy a buscarlo y lo aplico para comentarte, me parece una muy buena opción.

Ahora bien lo que no sé es como eliminar las diferencias que me quedan, o sea, como hacer para que todo el proceso de cierre de costos cuadre exacto, tanto los gastos reales como la revalorización de las ordenes a tarifa real, ya que esas diferencias siempre quedan, son muy pequeñas, por ejemplo el mes pasado fue apenas de usd$16 de todos los millones, sin embargo, entiendo que no deberia quedar nada si todo el proceso ha sido ejecutado exitosamente y los centros de costos deberian cuadrar con saldo "0".

Les has sucedido tambien este error?

[oscar_dc]

Hola a todos...

Considero que siempre es bueno hacer retroalimentación cuando se solucionan los errores para que los consideremos, en este caso el consejo que me dio Ricardo acerca de cambiar los parametro de la KSII fueron correctos y solucionaron mi problemas, quiero recalcar que este consejo puede ayudarles mucho cuando les queden algunas diferencias en el cierre de costos, en mi caso practicamente las redujo a cero y es un parametro que se deberia cambiar en el cierre de costos, claro adicional busque información en el foro de SAP y tambien se agrego estos cambios para la KSII (incluyendo los que menciono Ricardo):

- Ingresar a la KSII -> detalles -> Opciones.
- N° pos. significantes: Subir a 10 o más, esto hace que en los cálculos internos de SAP se consideren más decimales haciendo el cálculo más exacto, por ejemplo si la tarifa es 157.889.5645, con el parametro predeterminado de SAP que es 6 se calculara con base en 157.889 (o sea, 6 posiciones) en cambio con las 10 posiciones se considerara 157.889.5645, esto es muy importante en paises donde el tipo de cambio es muy alto como el caso de Colombia, ya que incluso si las tarifas llegaran a ser de millones podria afectar bastante, hay que considerar que tampoco se debe exceder mucho porque creo que podría causar problemas en tiempo de ejecución y tira el programa.

- Quitar el check de "Sin Optimización": este check evita la funcionalidad de SAP de optimizar el cálculo, en este caso esto ayudo bastante a reducir las diferencias por utiliza más decimales como propusimos en el punto anterior.

- Los otros parametros tambien pueden incluir pero en mi caso con las pruebas que hice y las modificaciones que hice en los dos puntos anteriores me bastaron para mejor por mucho las diferencias, sin embargo, brevemente les comento el margen de tolerancia es para establecer cual es el porcentaje máximo de diferencia entre la tarifa plan y la real, si requieren averiguar más del tema pueden consultar las notas de SAP:

Costo Real:

1- Note 721487 - Balance remains on cost center after price calculation
2- Note 597159 - Price calculation seems to calculate incorrect values
3- Note 747309 - Price calculation calculates incorrect cost component split
4- Note 156563 - Settlement after activity allocation revaluation

Información relevante:
Note 27922 - Info Settlement types and quantity settlement
Note 30291 - Differences between CO and FI in grp.currency
Note 39919 - Introducing parallel currencies in FI
Note 73237 - CO not updated according to exchange rate types
Note 730766 - Settlement after revaluation Missing offsetting entry
Note 846933 - CO settlement Error with unknown currency types in FI
Note 1066394 - Group currency is not transferred in FI postings (FBB1)

espero que esta información les pueda ser tan útil como me fue a mi en su momento.

Saludos y gracias.

[Rastis]

Estimado, busqué este tema por todos lados en foros en ingles y no lo pillaba

Gracias funciono perfecto!