ayuda para diseñar tablas....
 

Hola a todos..

Tengo unas dudas para diseñar unas tablas que deben almacenar el inventario de un sistema que me piden que desarrolle...

si bien la tabla Productos generalmente la diseño con la sgte estructura:

Pro_Codigo -> codigo producto
Pro_Articulo -> nombre producto
Pro_Detalle -> descripción detallada del producto
Pro_Valor -> valor unitario de compra sin impuesto (último valor)
Pro_Categoria -> categoria a la cual corresponde (herramientas / maquinas / etc)
Pro_Stock -> cantidad en bodega..

me complica el siguiente requerimiento...

Como se realizan Obras de Mantención... tendra que manejar presupuestos por Obra... por lo cual necesito saber el costo real de los materiales utilizados... para explicar mejor, lo haré con el sgte ejemplo

Articulo: Sacos de Cemento
Existen en bodega 30 sacos de cementos, comprados a $3.850 c/u
La Obra necesita un estimado de 120 sacos de cementos...
Se compran 90 sacos (la diferencia) a $4.500 c/u... pero por ampliación de obra se necesitan más sacos.... y se compran 50 sacos a un precio de $5.600 c/u

Por lo tanto.. cuando registro un ingreso de inventario... con suerte registro el primer precio o el último precio de compra... por lo cual el costo que se registrará será de ... y según lo anterior.. puede que un producto tome x precios distintos... dependerá de la cantidad a comprar.. lugar... descuentos por cantidad que realicen... etc..

170 sacos de cemento a $3.850 (si tomo el valor inicial) => $654.500
170 sacos de cemento a $5.600 (si tomo el valor final) => $952.000

cuando el costo es de

30 sacos a $3.850 =>$115.500
90 sacos a $4.500 =>$405.000
50 sacos a $5.600 =>$280.000 Total Gastado $800.000

No se si me explique... pero alguien podria dar una forma de tratar con este sistema de prorrateo de precios...

Salu2 :p:D

Hola
No se si entiendo bien, pero para mi esta hablando de varias tablas, no solo inventario.
Tablas:
Clientes
Materiales
Obras en progreso
Materiales Estimados por obra (estimados)
Materiales Usados en obra.(reales)
El resto es en realidad solo cálculos en base a los datos, reportes etc.

Es parecido al sistema que uso en mi empresa, solo que yo no hago estimados.
Saludos

El problema amigo Azul;), es que por lo general no es adecuado llevar el precio de compra o de venta en la misma tabla que hace de inventario. Debido principalmente por el problema que estás pasando.

Lo correcto sería que lleves dos tablas más: Compra y DetalleCompra.
Tu tabla compra llevará entonces la información que distingue a una compra de otra: una PK que actue como identificador, un campo fecha, una FK hacia el proveedor, y demás...

DetalleCompra por tanto contendrá: una PK, una FK hacia la PK de la tabla Compra, una Fk hacia el producto en cuestión, un campo precio de compra, un campo cantidad. Eso como mínimo.

Pues por ahora eso es lo mínimo necesario.
Pero como recomendación amigo te puedo decir que analices mejor el tema del movimiento de stock...
Por lo que leo se trata de una empresa que se dedica a obras de construcción si es así sabrás, o te informarás de que los pedidos por lo general se hacen x días antes de que el stock llegue a su mínimo. Pero hay casos especiales... por ejemplo el de los materiales con que se realiza el cemento.
Por lo general, se estila pedir estos materiales bajo demanda y no tener demasiado en stock ya que es un elemento relativamente caro y una vez hecho el concreto debe usarse. Se pide lo justo y necesario... ni más, ni menos. Una vez hecho el concreto se debe usar en el momento, nada sobra.
Debido a esto, en algunos lugares las empresas ofrecen bolsas de diversos tamaños, de tipo de diferentes mezclas.

Creo que con lo que he dicho, más lo que aportó Carlos se entiende la idea.
Si necesitas saber más sobre obras avisa. Veo como le pregunto a mi padre (El estuvo un buen tiempo en el sector Obras Públicas de la Municipalidad y entiende del asunto).

Holas...

Bueno... gracias por responder..

super validas ambas opiniones, pero creo que me falto agregar información... aqui les dejo mi diseño de la base de datos..

La pregunta en realidad iba por otro camino.... el requerimiento fue de COSTOS PROMEDIOS...es decir que pueda realizar un promedio (o conocer el costo real) de los articulos utilizados...

Esto me lo pidieron porque se puede dar el caso que en la bodega exista un articulo que lo pueden usar en un Proyecto...eso articulo posee un precio de compra... si el stock no es suficiente.. deberán adquirir más stock para satisfacer el requerimiento... y tambien puede pasar que el valor de los nuevos articulos no sean los mismo...entonces, lo que me piden es saber que cuanta cantidad de articulos se emplearon en la obra...eso lo se por las salidas de Bodega... pero además, si existe 1 articulos que durante la ejecución de la obra se adquirio más de 1 vez.. y cada vez fue a precios diferentes... que me indique claramente cuanto fue el costo real.... por que como les decia anteriormente...con el ejemplo de los sacos de cemento...que no es lo mismo decir que gaste 170 sacos de cemento y el costo fue $952.000 o $654.500, cuando en realidad el costo fue $800.000

Bueno, en el diseño podrán apreciar que utilizo diferentes tablas para organizar las ordenes de compra y detalle, facturas de compra y detalle, facturas de venta y detalle, salidas a producción y detalle... etc...

Salu2... :p:D

Veamos si entiendo ahora:
¿Tu duda pasa entonces por determinar donde y/o como mantener la información del/para el costo promedio? Es decir... ¿cual de las tablas te es viable y útil para mantener dichos datos?

Si es eso... te soy sincero... no te sabría decir ahorita... me pillaste medio dormido. Mañana me pillas mejor.

No es por criticarte, debe ser mi falta de costumbre, pero a primera vista me costó interpretar bien la flecha, por momentos me parecía indicar el sentido de "varios" y por otros momentos el de "uno". Lo que no comprendo bien es la nomeclatura, D para detalles, F para ¿factura? y ¿G?
Se que no me incumbe... sólo ando curioso.

Lamento tener mi cerebro apagado:(, pero una vez que duerma recuperaré energias.

Saludos,

algo por el estilo... osea si es necesario agregar otra tabla.. la agregamos...

No problem amigo Delphius....siempre es bueno darle más de una buelta...sobre todo al diseño de una base de datos...

bueno...eso es problema del programa en donde realizo el modelamiento... es el SDesigner 5....así trabaja

D -> Detalle
F -> Factura
G -> Gasto, relacionado a un Centro de Costo

no problem... si no quisiera que se metieran en mi diseño.. no lo ubise posteado... asi que todo es bienvenido... al fin y al cabo es mi diseño... y sabre tomar los consejos que me parescan más adecuados.. y los implementare... las demás opiniones tambien las tomo como referencia.... y como dije.. no problem

Bueno... Delphius.. que duermas bien.. y que sueñes con los angelitos...angelitos angelitos...mientras yo tendre pesadillas con el diablo....

Salu2:p:D

Amigo, con esos angelitos no creo que pegue un ojo durante la noche!:D;)

Bueno, mejor te tiro a dormir que mañana me espera un dia largo.
Saludos, y tu también sueña con los angelitos;):D

Saludos,

Bueno BlueSteell,
Por el momento, creo que ya a ser más conveniente aplicar una pequeña regla:

Asi que, momentáneamente puede ser más seguro destinar una tabla para dichos datos.
Un mejor análisis y examen de otros requisitos pueden terminar confirmando que es más seguro disponerla en otra tabla, o que sólo aporta ruido y sería conveniente alterar una tabla agregando los campos necesarios.

Yo además, señalaría en la documentación del proyecto que posiblemente se ha encontrado un punto débil en el análisis de los requisitos y que se necesita de un mayor estudio aquí.

Saludos,

Una pregunta : Qué pasa si finalmente, por ejemplo, esa obra no gasta siquiera 120 sacos de cemento, sino 100.

Los veinte sacos que sobran , cuales son, los más baratos, los más caros ? De cual se cogió si se almacenaron todos juntos ?

Desde siempre, para mi, se hace necesario trabajar tanto con el precio medio de un artículo, como con el último precio de compra, entre otras cosas para ver la variación de precios.

No sé si te has planteado esto correctamente, o a lo mejor el equivocado soy yo.

Si me aclararas este punto, a lo mejor te puedo ayudar mejor.

;)

Hola gluglu...

bueno, con respecto a la pregunta de si sobrasn sacos... esos no deberian cargarse en la obra... obvio... pero los que estan en bodega serian los salen primero....por el tipo de empresa utilizan la metodologia FIFO...

creo que esto me puede servir....

la idea es poder ver la mercaderia que esta en existencia...y ver todos los ingresos que tubo con sus respectivos precios...y que la mercaderia que vaya saliendo asuma el precio (costo) de la compra correspondiente.... o algo así...

Salu2:p:D

Amigo gluglu, por algo yo decía que en cuestiones de productos para elaborar concreto, asfalto y/o cualquier producto relacionado con estos NO SOBRA NADA. Se pide lo absolutamente necesario para hacer el trabajo.
Si se compran 100, a los 100 se usan.
Es un producto que por lo general tiene un ciclo de vida en stock muy corto. No se almacena en grandes cantidades.

Saludos,

Les haré otro alcancé por si lo pueden aplicar...

Yo trabajo con programas del sector alimentario y hostelero, donde, por legislación sanitaria, se debe llevar un control mas exhaustivo de la bodega que incluye la fecha de caducidad y el lote. Con lote nos referimos a una partida de producción. Por ejemplo, una empresa proveedora hace conservas de maíz el día 10 de abril de 2008 con el lote 00124 y luego otra partida el día 14 de abril de 2008 con el lote 00125.

Así, si un día la empresa decide hacer una preparación de alimentos con maíz, se produce una salida de la bodega de conservas de maíz con cierto o ciertos lotes y fechas de caducidad. Por ejemplo:

Cantidad Unidad Producto Lote Caducidad Precio
25 Bote 4 KG Maíz 124 10/04/2015 12.56
124 Bote 4 KG Maíz 125 14/04/2015 12.68

Claro esto exige, llevar un poco más de control en la bodega (al hacer las entradas, salidas y mermas), pero se tienen otras ventajas.

Lo que tendrás que analizar es si puedes aplicar estos conceptos a tu sistema. Obviamente, no sería necesario trabajar con caducidades pero el concepto de lote si es aplicable y para evitar problemas, como los que ha comentado gluglu, habría que dar salida al lote más antiguo siempre.

Espero haberme explicado bien y que te sirva de algo... :)

Creo que me demoré un poco en escribir :p. Si hacen ese tipo de rotación de stock, no habrá problema al llevar el control del lote.

Hola amigo [BlueSteel], a veces yo saco ideas de ésta página por ejemplo puedes ver esta estructura muy básica pero hay varias mas.

Salud OS

Si es como tu dices, que mientras que existan sacos de cemento antiguos, siempre se saquen los antiguos antes que los nuevos (FIFO), entonces el precio medio no te servirá al 100%.

Supongo que sabes que para calcular el precio medio de un artículo se utiliza la siguiente fórmula :

(Exist. Antigua * Pr.Med.Antig) + (Nueva Compra * Nuevo Precio)
Nuevo Precio Medio = -----------------------------------------------------------------
Exist. Antigua + Nueva Compra

Si te vas a regir por el sistema FIFO que propones, pues te propongo la siguiente lógica :

Tabla de compras :

50 sacos x 3.850 $ (de los cuales ahora mismo en almacén me quedan 30)

Deberás de llevar un registro de existencia actual que ponga 30.

Nuevas compras :

90 sacos x 4.500 $
50 sacos x 5.600 $

Los registros de compra se ordenan secuencialmente (o tb. por fecha de compra)

Existencia nueva actual : 170.

Retiro para la obra (p.ej.) 40 sacos en una primera tanda.

Primer cálculo : 170 (Ex.Act.) - 40 (que retiro) = 130 que tiene que quedar.

Voy hacia atrás en el registro de compras hasta que la suma de las últimas compras sea mayor que la existencia restante que acabo de calcular.

Ejemplo en este caso
50 última compra (< 130 .... sigo)
50 + 90 = 140 (> 130 ... paro)

140 - 130 = 10. Es decir, de la retirada de 40 sacos, 10 son al precio que compre los 90 (4.500 $), y 40 - 10 = 30 son al precio de la anterior compra que tendré que buscar (3.850 $).

Costo de la 1ª tanda de 40 sacos :
(30 x 3850) + (10 x 4500).

Al retirar 40 mi nueva existencia se convierte en 170 - 40 = 130.

Siguiente tanda de retirada : 100 sacos.

Nueva operación : 130 (Ex.Act) - 100 (que retiro) = 30 que tienen que quedar al final de la segunda retirada.

De nuevo voy para atrás en el registro de compras.
50 (última compra) (> 30 de mi calculo) .... paro

50 - 30 = 20 sacos que tengo que coger de la última compra a 5.600 $

100 sacos retirados - 20 sacos al último precio = 80 sacos al precios anterior de 4.500 $

Total consumido :

40 sacos
(30 x 3850) + (10 x 4500) = 160.500

100 sacos
(80 x 4500) + (20 x 5600) = 472.000

Total = 632.500

Si finalmente gastos los 30 sacos que te quedan en existencia, por la misma lógica te saldrá que esa retirada de 30 sacos será a 5600 $ cada uno, es decir, 168.000 $.

El total de costo habría sido entonces = 800.500 $ que es precisamente la cantidad que buscas.

Este sistema, como comprobarás, además te permite llevar la existencia actual, que según mis tandas de retirada han sido sucesivamente, 30, 170, 130, 0.

Esta es la lógica vista con un ejemplo práctico y numérico. Ahora te toca programar ;) ;) :D

Espero te haya servido y mi planteamiento sea el que tu propones.

Saludos :rolleyes:

Mientras escribía, se me adelantaron otros comentarios. Espero a pesar de todo que te sirva lo que explico. ;)

Creo que voy cazando la mano...
Por lo que voy entendiendo... ¿entonces pareciera ser que lo correcto sería llevar el control de forma parecida a por lotes como comenta gabo?

Un precio de compra, es un "lote". Otro precio de compra, otro "lote". ¿Esa es la idea?

Saludos,

Más o menos esa era la idea que se me estaba ocurriendo implementar...

Habrá que ver que le parece la idea a BlueSteel...

Gracias a todos...
 

Gracias a todos...

muy buenos comentarios..... me gusto el sistema de lotes de gabo... y tambien la explicación que dio gluglu.... vere como realizo el proceso...

creo que la explicación de gluglu me es más facil implementar a través de los detalles de ingreso a bodega...los cuales lo tengo con precio....y fecha...

Egostar... voy a chequear la pagina... se ve interesante...

Bueno... ahora se tendrá que traducir todo a codigo y ver como anda....

Salu2 y gracias :p:D

Cierto, muy interesante... Gracias por el dato... :)