34 respuestas en este tema

[MyVic]

Hola Maestros
Soy nuevo en este blog, entre por los grandes aportes que realizan para los pequeños saltamontes, tengo la siguiente pregunta por favor si pudieran responder y entender mi pregunta.

Necesito trabajar con mas de 2 unidades de medida ejemplo
1.- Si compro por cajas y tambien puedo vender por cajas o vender por kilos y gramos (3 unidades de medida)
2.- Si compro por barra puedo vender cm cubico o kilos

Espero me hayan entendido, les estare muy agradecido por sus comentarios

Gracias DELPHIACCES

[poliburro]

Podrías darnos más info sobre lo que deseas hacer y que es exactamente lo que tienes por duda?

Saludos y bienvenido al foro 

[Wilson]

Bienvenido al foro MyVic, siéntete como en casa.

Las respuestas a tus preguntas son:

1. SI
2. SI

Ahora, como hacerlo, depende de muchos factores, necesitamos más información de tu parte,  por ejemplo: Es probable que necesites una base de datos, ¿Cual?, ¿Dispones ya de algún diseño de la DB?, ¿Haz adelantado algo?.

En los post anteriores hay buenas ideas e información de como hacerlo, si te atoras en un punto específico no dudes en preguntar.

Un cordial saludo.

[MyVic]

Poliburro y Wilson, gracias por contestar con tanta rapidez y al Foro por supuesto por compartir la experiencia de grandes Maestros.

Tratare de explicar de mejor forma

Estoy realizando un sistema para una ferreteria donde compran por cajas, barras, rollos, etc
1º La venta puede ser por caja asu vez por  peso en kilos (ej. clavos, este tiene 2 unidades de medida)
2º La barra puede ser vendido por barra tambien se puede cortar a medida en centimetros y tambien pueden vender por peso en kilos(ej. esto llevan para realizar aros, anillas etc, lo cual moldean despues)
3º Rollo este es alambre venden tambien por rollos por metros tambien lo hacen mallas y venden como mallas

La pregunta es como manejar un producto que tiene 3 unidades de medida o mas en base de datos

Muchas gracias por el interes

[Wilson]

La pregunta es como manejar un producto que tiene 3 unidades de medida o mas en base de datos

Amigo te sugiero, que intentes creando una tabla de equivalencias por cada sistema de medidas o "familia de medidas" (Volumen, masa, longitud, etc) con un patrón de conversión, tal y como lo explicamos en post anteriores de este mismo hilo. Luego con eso, puedes manipular los productos no solo en 3 unidades de medidas sino en cualquier múltiplo o submúltiplo del patrón de conversión, bastaría con un trigger (dependiendo de la DB que uses) para que tome la unidad en que fue manipulado el producto y lo convierta a la unidad PATRON para hacer las respectivas operaciones en el inventario.

Ahora para consultar un inventario, basta pedirla en la unidad Patrón  y convertirla a la unidad en que el usuario lo quiera ver.

Lee con detenimiento los post anteriores de este hilo e intenta iniciar creando las tablas, si te atoras en algo, no dudes en preguntar.

Un cordial saludo.

[Delphius]

Hola MyVic,
Este sitio es un foro, con una comunidad que lo sostiene... no es un blog. Te agradecería que no confundas las cosas.

Como bien comenta el compañero Wilson, si lees con mucha atención y detalles todo el hilo entero te darás cuenta que ya buena parte de lo que buscas está contemplado. Es más, hasta quizá lo ya propuesto sirve perfectamente sin cambios.
Fíjate que nada impide que para un producto se diseñe una tabla de pesos para diferentes medidas, justamente lo que tu necesitas. 

Te invito a que expongas tu caso lo más profundo y detallado posible y en lo posible con la estructura preliminar de tu base de datos para ver como lo has estado analizando.

Ahora, si resulta ser que necesita de la posibilidad de convertir de un sistema de medida a otro, pues habrá que evaluar mejor el panorama.

El punto es que una cosa es que uno pueda concebir un sistema de medida hipotético como
CAJA_BAYASPIRINA que puse como ejemplo:
pastilla (1/30) < Tableta (1/3) < Caja (1) < Paquete < (12)

Y otra que lo que tu busque que se pueda pasar o mezclar sistemas de medidas:
gramos-pastilla (factor_gr-pastilla) < Tableta < Cm3Caja (factor_cm3Caja)

La pregunta que debo hacerte, es ¿Cómo debiera de comportarse el sistema de medidas? ¿Cuáles serían sus (sub)múltiplos? Aprovechando tu ejemplo:

Producto: Barra
Sistema 1: submultiplos-barra < Patron-Barra (1) < múltiplos-barra
Sistema 2: submultiplos-metro < Patrón-Metro (1) < multiplos-metro
Sistema 3: submultiplos-kilo < Patron-kilo < multiplos-kilo

O es que la idea sea algo como:
Sistema Esoterico Barra: metros < Barra < kilos

¿La idea es que se requiera pasar de un sistema a otro? ¿Qué define a una barra? ¿O a una barrita? ¿Cuándo se considera 3/4 de una Barra? ¿En kilos, y/o en metros? Y así lo mismo para todo producto que imagines.

Si nos puedes poner en mejor perspectiva podremos ver hasta donde podemos llegar con lo que se ha venido discutiendo, y que necesita afinarse para tu caso.

Saludos,

[MyVic]

Estimado Delphius

Disculpas mil por no contestar a tiempo, estube de viaje y gracias por aclarar mis dudas sobre el foro

La forma que normalmente use es vender en 2 unidades de medida Ej. Caja y Unidades

En el caso de una ferreteria te pongo un ejemplo, compran una barra de hierro que debe tener 2 metros de largo y un diametro 15 cm, este material lo vende por barra, tambien lo venden por peso en kilos(cortes) o a medida en centimetros(cortes), ya que los que compran realizan anillas poleas etc.

De nuevo gracias por leer mi consulta

Saludos a todos los integrantes del foro

[Delphius]

Hola MyVic,
No hay problemas en las demoras, aquí entendemos que cada uno tiene sus obligaciones. Después de todo, los que construímos y formamos esta comunidad somos personas que tienen sus trabajos y/o changas. Nos apoyamos entre todos en nuestro tiempo libre.
De hecho, yo tampoco ando con demasiado tiempo ultimamente.

Si te vas al último post de la primera página del hilo, observarás un DER preliminar de como llevar un sistema de múltiples medidas y pesos para un producto:

Sistema -1 --- M - Medidas - 1 --- M - Multiplos - 1--- M - TablaPesos - M ---- 1 - Producto

Reitero el consejo que se te ha dado: por favor lee el hilo entero que se han estado dando mucha información que puede ser útil. Y como dije antes, no estaría mal que nos dieras a conocer en más detalle tu caso, y en lo posible que nos comentes sobre tu diseño para tener una mejor orientación a lo que nos enfrentamos.

Así como está contemplado ese diseño que propuse nada impide que un producto no esté relacionado a dos o más sistemas de medidas. Fíjate en como se desarrolla la cardinalidad:
* Un producto ofrece una tabla de pesos para cada uno de los múltiplos de UN sistema de medida.
* Un sistema de medida ofrece un conjunto de múltiplos que luego cada producto utilizará.
Ergo: existe una relación indirecta del tipo muchos-a-muchos (M:M) entre Medidas y Productos.

La dificultad en tu caso no está en el uso de las medidas, sino en como asociar y llevar un buen control de como relacionar la relación entre diferentes medidas. Fíjate que nada impide formar una tabla de pesos para un producto que contenga o relacione datos de dos o más y diferentes sistemas. Visualmente vendría a ser algo como:

Sistema de medidas:
IDMedida - Nombre - Descripcion
1 - Masa - Sistema tradicional de masa
2 - longitud - Sistema tradicional de longitud
2 - BarrasAcero - Sistema de medida diseñado para diferentes cortes de barras de acero


Múltiplos:
IDMultiplo - MedidaID (fk:IDMedida) - Denominación - Nombre - EsPatron
1- 1- mg - miligramo - no
2 -1 - cg - centigramo - no
3 - 1- dg - decigramo - no
4 - 1- g - gramo - si
5- 1- dag - decagramo - no
6- 1- hg - hectogramo - no
7- 1- kg - kilogramo - no
8 - 1 - mag - miriagramo - no
9 - 1- q - quintal - no
10 - 1 - t - tonelada - no
--------------------------------
11 - 2 - mm - milímetro - no
12 - 2 - cm - centímetro - no
13 - 2 - dm - decímetro - no
14 - 2 - m - metro - si
15 - 2 - dam - decámetro - no
16 - 2 - hm - hectómetro - no
17 - 2 - km - kilómetro - no
--------------------------------
18 - 3 - b - Barrita - no
19 - 3 - bc - Barra Chica - no
20 - 3 - bm - Barra Mediana - no
21 - 3 - be - Barra Estandar - si
22 - 3 - bg - Barra Grande - no

Luego imagínate que tienes un producto en cuestión:

IDProducto - Descripcion (*)
1 - Barra de acero forjado de dureza 3N

(*) En unos post antes sugerí mantener una separación conceptual entre lo que es una descripción de un producto del producto en cuestión. Para este caso para simplificar y para que se entienda la idea es aplicable.

Luego lo que nos resta es asociar a esos múltiplos pesos específicos que hacen a este producto en particular. Observa que nada impide hacer referencia a diferentes unidades:

IDTablaPesos - MultiploID (fk:IDMultiplo) - ProductoID (fk: IDProducto) - Valor
1 - 1 - 1 - 0,001
2 - 2 - 1 - 0,01
3 - 3 - 1 - 0,1
...
10 - 10 - 1 - 1000
----------------------
11 - 11 - 1 - 0,001
....
17 - 17 - 1 - 1000
----------------------
18 - 18 - 1 - 0,25  // esto es la 4ta parte - Barrita
19 - 19 - 1 - 0,33  // esto es la 3ra parte de una barra -> Barra Chica
20 - 20 - 1 - 0,5 // esto es la mitad de una barra -> Barra Mediana
21 - 21 - 1 - 1 // esto es una barra completa, estándar -> Barra Estándar
22 - 22 - 1 - 1,5 // esto es una barra y media -> Barra Grande

Entonces hemos conseguido asociar un producto su propio juego de pesos para diferentes medidas. Para el ejemplo: masas, longitud y un sistema hipotético pensado para barras de acero.

Ahora viene lo complejo. ¿Cómo vamos a controlar el stock si tenemos diferentes medidas con las cuales operar? Es necesario para esta tabla de pesos poder hacer una relación de conversión entre uno y otro ¿Cómo? Añadiendo una tabla justamente que vincule a cualesquiera de un registro de la tabla de peso de un sistema a otro. Para este caso tenemos las siguientes posibilidades:

Masa <-> Longitud
Masa <-> BarrasAcero
BarrasAcero <-> Longitud

Entonces para cada entrada en TablaPesos le podrá corresponder varias conversiones para otras entradas en la misma Tabla. Esto nos lleva al siguiente esquema:

delphi

TablaPesos-1---M-TablaConversion
  |			|
  +-1-----------------M-+

Si, parece algo de locos. Se trata de una tabla auto referenciada de forma indirecta. Observa que TablaConversion hace de tabla intermedia, lo que permite hacer una relación (M:M) para la tabla TablaPesos a si misma.

La estructura para TablaConversion podría ser algo como:
IDConversion: PK
DesdeID: Fk -> TablaPesosID (clave primaria de TablaPesos)
HaciaID: Fk -> TablaPesosID (clave primaria de TablaPesos)
Valor: real // factor de proporción entre un {múltiplo, peso} de un sistema y otro

Lo más adecuado sería almacenar únicamente la conversión hacia el {múltiplo, peso} patrón. Es decir por ejemplo desde Barra Chica a gramos, o de kilogramos a Barra Estándar. Pero nada impide que se ingreses otras.
¿Porqué sugiero directamente a las patrones? Porque de este modo es fácil hacer los cálculos y todo se termina almacenando en un valor patrón y es fácil de comparar... No es bueno por ejemplo que para un producto leas que existen 345,4 kg y luego para otro que existan 674654,1 mg.
El propósito de las tablas de Pesos, es permitir el alta de movimiento de los productos en diferentes medidas, que luego éstas gracias al campo valor se llevan a su patrón. Digamos que se ha adquirido (comprado) 6 kg, entonces el usuario indica que está por ingresar material expresado en kg pero internamente el sistema lo convierte en el patrón:
Cantidad a ingresar = 6
Múltiplo = kg -> Valor = 1000 veces el patrón
Cantidad calculada = 6 * 1000 = +6000g.

Y ahora supongamos que se vendió 30 dg:
Cantidad = 3
Múltiplo dg -> Valor = 0,1 veces el patrón
Cantidad calculada = 3 * 0,1 = -0,3g.

Entonces el sistema incrementa/decrementa en estas unidades calculadas. Pero he aquí entonces que surje ahora la tabla de conversión. Lo que define a la Barra Estándar es justamente una barra de 3kg (o 3000 g), cuya longitud es 0,9m. Pues bien... suponiendo que el material es completamente uniforme y por tanto mantiene sus propiedades entonces podemos decir que una Barra Mediana que es la mitad, debería ser de 1500g y de 0,45m.

Veamos como se llenaría TablaConversion con algunos ejemplos:
1 - 20 - 4 - 1500 // Barra Mediana a gramos: 1 Barra Mediana equivale a 1500g
2 - 12 - 21 - 0,01 // Centímetros a Barra Estándar

Entonces cuando se ingresan dos barras medianas, a gramos resulta en:
Cantidad = 2
Calculado en gramos = 2  * 1500 = +3000g

Cuando se venden 40cm; a barra estándar resulta en:
Cantidad 40
Calculado en barras estándar = 40 * 0,01 = 0,4

Lo que significa que aún queda el 60% de una barra estándar restante. Observa que si se hubiera vendido 45cm el cálculo arrojaría 0,45... justo lo que hace una barra mediana.

Entonces, independiente del sistema que se indique en que se va a producir la operación llevamos el cálculo a la los patrones de cada uno de los sistemas que hemos pensado. De este modo el stok se lleva y se calcula en todos los sistemas y no en uno sólo. Al momento de presentar el stock general uno deberá mostrarlo por cada sistema y para cada producto. Como una de doble entrada:

Producto | Sistema1 | Sistema2 | ... | SistemaN
Producto1 ...
Producto2 ...
...
ProductoN ...

Si un producto no se expresa en alguna unidad simplemente se coloca como N/A.

Espero que con esto se te haya refrescado las cosas. Queda en ti hacer las revisiones y ajustar esto a tu caso. Ten en cuenta que desconocemos los límites, condiciones y/o restricciones a la que te ves sujeto. Aquí nos vemos obligado a generalizar.

Saludos,

[Delphius]

Hola,
Como seguramente se puede apreciar, el diseño propuesto sobre la tabla de pesos tiene un ligero defecto: para los sistemas estándares se está repitiendo los mismos valores:
mili - 0,001
centi - 0,01
deci - 0,1
deca - 10
hecto - 100
...

Si bien no es tampoco un gran pecado, y se ha buscado ofrecer un diseño al menos lo más simple y que se pueda entender, es posible evitar esta repetición de valores en donde lo que cambia en realidad es el nombre o denominación propia de la unidad. Entonces se podría concebir una única tabla de múltiplos ya con los valores fijados y hacer que en todo caso se agregen sistemas de unidades con la denominación correspondiente a la que referencian.
Esto favorece otro punto se logra separar los sistemas de unidades estándares de los "inventados". Llamemos a estos últimos, sistemas de stocks. Entonces gracias a esta separación lo que queda es formar una tabla de conversión de un sistema de stok a otro, y/o a de las unidades.

Dejo este análisis en suspenso. 

Saludos,

[cram]

Dado que llegué aquí desde un enlace. Aclaro porqué agrego algo dos años después.
Soy usuario de DelphiAccess desde el 2013 y por esa razón no ví este tema como tema nuevo.

La propuesta de Wilson es muy buena.
Pero el asunto de volverse loco con un método complejo de conversión de medidas, cuando no es necesario, no me parece buena idea.
En el caso de la implementación en esa panadería que cita Wilson es muy útil, ya que por ej. la harina se compra por Kg y se vende como producto elaborado. El sistema que implementa el control de existencias en este caso no se llama de gestión, sino que es más cercano a un sistema de control de producción (ERP).

Cuando se trata de contar existencia de una forma distinta en la entrada como en la salida, incluso cuando en la salida es variada, las medidas no son muchas, ya que una pequeña tabla al modo que indica Wilson bastará. Por otra parte, no se vende fraccionado en un supermercado más que por peso y si existe algún bar o comedor dentro de él y las salidas se registran como propias del mismo mercado, se agregará la fracción de volúmen para las bebidas.
En el caso de las pastillas, las farmacias pueden implementar una venta fraccionada, pero las compras no se hacen en términos de pastillas o fracciones, sino que se hacen en cajas como unidades, pero cada presentación tiene un código diiferente y es un producto de mercado también diferente, por lo que las existencias no se mezclan. A los sumo, se puede utilizar cierta presentación para la venta fraccionada y otra presentación para venta en caja cerrada. No es importante conocer las existencias en términos de unidades pastillas, más sí en unidades de compra, pues el stock se repone en unidad de compra, no de venta.

En el caso de un restaurante o un bar, sí. Las tablas de conversión son muy útiles, ya que existe producción. Aquí una cerveza, por ej., si se vende por vaso o jarra, normalmente no se compra por botella, sino a granel o por barrica. Mientras que si se vende por botella, se cobra la botella y se compra la botella, es simple. Para el caso de una bebida como Coca-Cola que tiene presentaciones grandes, quizá un comercio pequeño quiera fraccionar en vasos y comprar botellas de 3L. La conversión de L a vaso es importante, pero puede resultar más importante o productivo hacer la conversión de producto comprado con producto vendido que es mejor (O sea Coca-Cola 3L a vaso, a vaso grande, etc., Coca-Cola de 2L a lo mismo, etc.)

Toda esta conversión depende del tipo de implementación y nunca es conveniente matar un "mosquito con una escopeta".
Esto separa a un ingeniero (o persona con pensamiento similar) de un artesano.

Saludos

[Delphius]

Como dice nuestro compinche Egostar... DEPENDE.
Bien dices Cram en que dependiendo de las situaciones se puede ir por algo más simple, y en otras se verá necesario hilar fino (y hasta más fino de lo que se ha propuesto en este hilo).
El tema de inventario/stock tiene su ciencia (de hecho en Investigación Operativa tiene su propia rama de estudio), aunque también obece a un arte que cada analista le da.
En el área del desarrollo de software hay grises. No necesariamente hay una sola respuesta, una sola solución. Sobre todo en bases de datos. Hay tantos diseños y propuestas como personas. Diseños distintos que responden a una misma problemática que ambos atacan y dan una solución. Cada quien tendrá sus pros y contras. Seguro. Si se hace lo simple desde una perspectiva, algo más complicado tendrá desde otra. Es el Ying-Yang.
Si hay una cátedra que nunca quisiera dar es esa. Recuerdo los debates que se armaban en clases, y en como la profesora debía ir viendo caso a caso y poner a discusión los criterios de cuando algo está bien o mal (descontando el tema de si uno usaba bien o no las reglas normales, claro).

Volviendo al tema de sotck, y que se compra en una escala mayor y se vende en otra "menor". Es algo habitual. Permítanme decirles, que al menos desde la Teoría de Stock y el análisis de Inventarios se concibe la existencia y el uso de más de un patrón de medida. Casi diría que es una regla y no una excepción. Por lo que es habitual que desde la tabla/gráfica ABC de inventarios nos encontremos justamente que se mide en un patrón pero que también existan otras medidas "secundarias" en las que se van transformando la materia. Yo al menos en los ejercicios que he visto cuando cursé la cátedra he visto esos casos.
Es típico en lugares que se dedican a transformación de materia prima en otra. Y en menor medida también visto en algunas áreas de consumo. Super/hiper y medianos mercados cuentan sus entradas y salidas en más de una medida. O bien usan varias que luego se convierten a una patrón. Esto es lo que hacen los sistemas de stock (sea o no un ERP) de forma automática.
De la mano de esto está vinculado el que se entiende justamente por producto y/o artículo... tanto para el consumidor final como para el cliente/usuario de la aplicación (cada uno tiene su visión). Por eso es que yo pongo tanto énfasis en esa palabra.
Y pongo un ejemplo para ilustrar a lo que nos puede llevar... ¿Un fardo o pack de 6 botellas es UN "artículo"? ¿O son 6 "artículos" de lo mismo? ¿O tratamos al pack como un "artículo" y a cada botella como otro?
Elíjase cualquiera de esos 3 criterios y arme un sistema de inventario que sea capaz de soportarlo y obtendrán en cada caso diferentes artilujios, pros y contras.

Saludos,

[egostar]

Hola

Mientras que si se vende por botella, se cobra la botella y se compra la botella, es simple. Para el caso de una bebida como Coca-Cola que tiene presentaciones grandes, quizá un comercio pequeño quiera fraccionar en vasos y comprar botellas de 3L.

Y pongo un ejemplo para ilustrar a lo que nos puede llevar... ¿Un fardo o pack de 6 botellas es UN "artículo"? ¿O son 6 "artículos" de lo mismo? ¿O tratamos al pack como un "artículo" y a cada botella como otro?

Las complicaciones vienen cuando el negocio no es una tienda de abarrotes, sino negocios donde se tiene que calcular por ejemplo "el costo de los insumos del mole poblano" donde la receta requiere de ciertas cantidades de "ajo, ajonjolí, bolillo, caldo, canela, carne, cebolla, chiles ancho, chiles mulato, chiles pasilla, chipotle, jitomates, almendras, plátano, nueces, pasas, clavo, perejil, pimienta, tortillas...."

Saludos 

[Wilson]

la receta requiere de ciertas cantidades de "ajo, ajonjolí, bolillo, caldo, canela, carne, cebolla, chiles ancho, chiles mulato, chiles pasilla, chipotle, jitomates, almendras, plátano, nueces, pasas, clavo, perejil, pimienta, tortillas...."

¡Qué insinúas? ... ¿Acaso algo bien picante? ...

Saludos

[cram]

Las complicaciones vienen cuando el negocio no es una tienda de abarrotes, sino negocios donde se tiene que calcular por ejemplo "el costo de los insumos del mole poblano" donde la receta requiere de ciertas cantidades de "ajo, ajonjolí, bolillo, caldo, canela, carne, cebolla, chiles ancho, chiles mulato, chiles pasilla, chipotle, jitomates, almendras, plátano, nueces, pasas, clavo, perejil, pimienta,

Por las dudas, unas cervezas (aunque no conozca ni la mitad de los ingredientes, me imagino)
Yo probé los chiles jalapeños (mi primo quien me los hizo probar, los comía como si fueran maníes), acá en la zona a algo más suave los llamamos ají "puta parió".

Pero para no perder el hilo. Seguro que se soluciona con una báscula muy sensible, de esas que usan para pesar en las tiendas dietéticas y se crea una tabla para cada ingrediente, supongo que las especias, granos, frutas, etc. se compran en grandes cantidades al peso. Ah... al pavo hay que pesarlo crudo al descontar el stock o tendremos faltantes.

[giulichajari]

Otro aspecto importante sobre la bayaspirina es que la forte por 20g y 10 unidades y la forte por  10 gramos y demas presentaciones ya sea por la cantidad del pack o por el peso es que "farmacologicamente" es el mismo producto, lo que cambia es el costo obviamente, es decir se puede separar el producto del articulo, entonces el usuario selecciona el producto y luego la forma de presentacion.

Es aqui donde se ve la ventaja del diseño orientado a objetos... aunque hay sistemas que tienen todos en el detalle y listo.