query historial de costo de articulo

[Former Member]

Que tal compa'neros, estoy viendo la manera de hacer un query para ver la historia de costo de un articulo, es decir quiero saber a determinadas fechas cual fue la historia del costo de un articulo.

Por ejemplo: ultimas 10 variacioes de costo

articulo12345 10.50 11.00 12.00 8.50 10.05 11.00 9.50 ........

Asi por el estilo, esto con la finalidad de ver un cambio drastico en el costo de un articulo que en este ejemplo seria que el costo se fuera a 40 o que bajara a 2.

Sap en la base de datos guarda registro de esto??

De igual forma seria posible hacer un TN que verifique que si el costo del articulo tiene una variacion del 20% para arriba o para abajo no deje crear el movimiento??

Gracias desde ya.

[Former Member · Accepted solution]

¿El reporte de Auditoría de stocks no te sirve? En ese reporte aparece el costo del artículo en cada operación.

eroblero

[Former Member · Accepted solution]

No por el es el costo en esa transaccion y lo que busco es una historia para identificar brincos importantes.

Segun la gente de SAP no se guardan registros de costos en alguna tabla pero pues por eso pregunto aqui si alguien sabe de alguna solucion.

[Humberto_Neira · Accepted solution]

Carlos,

La tabla que buscas es la OINM. Esa es la tabla que el producto usa para almacenar el costo item en cada transacción. El reporte de auditoria, busca su información desde esa tabla.

Lo que tu pretendes hacer para analizar la variación de costos, debe ser un proceso que base su lógica de desarrollo sobre esta tabla. Alguna vez estuve pensando como hacer esto, y lo que se me ocurrió fue algo asi.

Procedimiento.

Paso #1:

Cargar en tabla temporal la historia de transacciones de items y costos.

Tabla 1:

fecha / item / bodega / costo

01-01-2009 item1 wh1 $10

01-01-2009 item1 wh1 $10

01-01-2009 item1 wh1 $10

Paso #2:

Procesando esta tabla, cargar una columna que determine la VARIACION DE COSTOS entre el registro actual y el registro anterior.

Tabla 1:

fecha / item / bodega / costo / variacion

01-01-2009 item1 wh1 $10 0

01-01-2009 item1 wh1 $12 2

01-01-2009 item1 wh1 $15 3

• siempre el campo variación es la resta del costo actual o del registro actual y el costo del registro anterior.

• para el caso del primer registro pones la variación en CERO.

• con esto ya tienes las variaciones que ocurrieron en cada transacción.

A partir de aqui esta lógica la puedes mejorar, para por ejemplo en vez de calcular la variación en dinero, calcular la variación en %%%. Si logras tener esta tabla temporal cargada, ya lo unico que queda es hacer una query final sobre esa tabla temporal para filtrar por aquellas transacciones cuyo campo variación este dentro de ciertos parámetros.

Lo único que se me ocurre es armar esto en tablas temporales, y programando store procedures sobre alguna BD de trabajo pero accediendo a la BD de alguna compañia B1.

suerte, pero como ves no es algo que se pueda hacer de manera muy facil, te recomiendo acudir a alguien que sepa bastante de programación directa en el SQL con store procedures y tablas temporales.

saludos

[Former Member · Accepted solution]

Si, vere si podemos hacer pruebas haciendo eso o traer a alguien que lo haga.

Muchas gracias por responder.

Sobre el TN crees que se pueda hacer?

[Humberto_Neira · Accepted solution]

El problema que veo de hacer algo asi en el TN es que:

-. en el TN tienes acceso al registro actual pero no al registor anterior, es decir, tienes el costo actual pero no me queda claro si siempre puedes tener acceso al costo que habia antes de esta transacción. El buscar el costo desde la tabla OINM, puede ser facil, pero en la medida que la BD crece en movimientos, el acceder a la tabla OINM tiene un costo que puede traer problemas de performance bastante complejos.

Me parece que dado que la tabla OINM es tan delicada, pues toda transacción que mueve inventario debe pasar por escrbir esta tabla y con el tiempo esta tabla tendrá mucho volumen, es mejor pensar en un esquema donde puedas tener un reporte pero de manera OFFLINE del dia a dia de las transacciones. Es mejor que quede como un reporte a pedido y que alli se dedique a hacer los calculos, y no ingreses lógica en el TN donde todo ocurre ONLINE y alli corres el riesgo de castigar muy fuerte la performance de B1.