CO-PC Cuadre cecos cierre de mes

[oscar_dc]

Hola a todos, tengo una consulta un poco al aire...

En la empresa que trabajo actualmente, tienen un concepto algo extraño la verdad nunca lo había visto, se llaman ordenes de redondeo, las cuales son ordenes de CO que limpian los saldos sobrantes de los centros de costos despues del proceso de cierre a final de mes.

En primer lugar sinceramente nunca había escuchado este concepto, según yo, siempre que se ejecuta la CON2 a final de mes ya se revaloriza todo y los centros de costos cuadran con saldo cero, solo queda pendiente la liquidación, siempre habia pensado que en la CON2 no quedaba ya nada que distribuir, ni siquiera un saldito.

A raíz de esto me surge la duda si hay algo que pueda estar faltando? Además ocurre algo singular, cuando liquidan estas ordenes de redondeo, en los reportes se ve por ejemplo un registro de usd$ 16, pero a la hora de ver las partidas individuales en moneda local, el equivalente puede llegar a tener sumas astronomicamente diferentes.

Alguien sabe porque puede ocurrir con respecto a estos dos temas?

Muchas gracias por los aportes, saludos.

[SidV]

Hola Oscar, si tenes acceso, sería bueno que pidas el BBP de CO de tu empresa.
En ese documento deberían haber explicado como se cuadran los cecos.

Es un modelo de costos, y lo que estas preguntando no podría responderte un consultor CO sin saber los requerimientos de la empresa, y el modelo que hicieron en CO para satisfacer las necesidades de distribución y exposición de costos.

De todas formas me ha parecido muy interesante la idea del sub-reparto de los redondeos a cecos. Excelente idea :P

Seguiré tu tema de cerca, a ver a qué llegamos.

[oscar_dc]

Hola SidV, como siempre gracias por contestar.

Te cuento, la verdad hace poco que estoy en esta empresa, y si tengo acceso a los BBP, sin embargo, el tema más que todo es que cuando decidieron poner SAP se guiaron por lo que dijo la consultoria, en realidad la idea de las ordenes de redondeo fue una especie de parche que pusieron con los años porque despues de todo el proceso siempre quedaban saldos.

El tema más grave aquí, es lo siguiente, para todos los paises hay una sola sociedad CO en dolares, yo la verdad hubiera propuesto una sociedad CO por país, ya que nadie sabe porque hay una sola sociedad CO, nadie sabe porque en dolares, no sé consolida en SAP, les atraza los procesos de cierre ya que al estar todos en una sola sociedad se bloquean entre si, en fin, nadie sabe porque se hizo así.
El punto es que, para estas ordenes de redondeo sucede algo extraño, cuando se visualizan los saldos en dolares (principalmente en Colombia) puede quedar un saldo en el mes de usd$12, pero si cambias el reporte a moneda local puede mostrar un saldo hasta de 10 millones de pesos, realizando un seguimiento a esto, he visto que estas diferencias ya se presentan desde los ciclos de subreparto, sin embargo, revisando todas las contabilizaciones no parece haber nada con una diferencia cambiaria tan extrema, solo en algunos casos he visto, que se pueden presentar diferencias más altas en las cuentas de depreciación, pudiendo ser la razón de que se registra a tipo de cambio historico, hasta el momento es lo único que se me ocurre.

Ahora bien, mi teoria es que esto se eliminaria si se pasara todo a una sociedad CO por operación, donde la moneda sea la misma que la sociedad FI, además de eliminarle todos los problemas que tienen hoy en día con respecto a esto tambien, tendrian los registros empatados.

Y hasta el momento esto es todo lo que tengo.

[SidV]

Wow, y qué empresa de consultoría hizo tan pobre el documento BBP de CO que no explica los requerimientos de la empresa? Si es como dices, que ni la empresa sabe pq se decidió que todas las sociedades FI apunten a una única CO (con moneda fuerte, de dolares), entonces es porque la consultora tomó la decisión de hacerlo como ellos quisieron?

Seguramente había algún fundamento, quiero creer.

No tienen ahora el soporte de la empresa que implementó?
Porque puedes abrir una incidencia con la duda que tienes, y que sea la empresa encargada del soporte la que deba analizar de donde vienen esas diferencias de millones para las sociedades.

Entiendes?

De todas formas, si dices que hay subrepartos, debes ver los ciclos.
Debe haber un INPA o algo que le diga al sistema de qué cecos tomar qué porcentaje (o numero relativo al total) para que antes de quedar en cero el proceso, tome esos "centavos" y los impute a los cecos de redondeo.
Todo esto del ciclo, debería estar especificado en algún documento funcional, dudo que los responsables de esa consultoría no hayan dejado un documento que respalde esta decisión.

El tema de porqué una sociedad CO, por lo general viene de la mano del tema de la moneda fuerte. En qué moneda ven los reportes de control de gestión interno? Si es en dolares, todo cierra para que se use una única sociedad CO.

Saludos

[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 :eek:. 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 :confused: , 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? :confused:

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!:)