Ir al contenido


Foto

unidades y equivalencias


  • Por favor identifícate para responder
34 respuestas en este tema

#1 delphinario

delphinario

    Advanced Member

  • Miembros
  • PipPipPip
  • 71 mensajes
  • LocationChile

Escrito 18 mayo 2012 - 01:15

Que tal estimados colegas,

  Estoy realizado un  sistema de punto de ventas y me he topado un pequeño pero  gran problema de concepto.

      Compra  de  Articulos----->PROCESOS------>Venta de Articulos
            (Entrada)                                                    (salida)

  NOTA:
  Este sistema pretende ademas    llevar un control de existencias  de las mercaderias.

    Bien el problema  radica  en el tratamiento del producto en si    ya se tanto en la compra  , inventario y en la venta
    Cuando digo tratamiento es que se me esta haciendo dificil  poder  comprender el siguiente tema:

    unidades :

    Por  ejemplo    si  se comparan 10  cajas del  producto X  y  cada caja  contiene  20 unidades de tal producto
  Como registro  este en el inventario  y ademas  si  se vente  por unidad como  manejarlo..

Espero  se me entienda  el dilema en el que me encuentro.

Agradeciria    sus comentarios.

Saludos

  • 0

#2 enecumene

enecumene

    Webmaster

  • Administrador
  • 7.419 mensajes
  • LocationRepública Dominicana

Escrito 18 mayo 2012 - 06:37

Normalmente el código de barra de los productos, la caja o paquete es diferente al de la unidad, pos por ahí pueden ir "los tiros".

Saludos.
  • 0

#3 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.446 mensajes
  • LocationMéxico

Escrito 18 mayo 2012 - 07:36

Hola

Por  ejemplo    si  se comparan 10  cajas del  producto X  y  cada caja  contiene  20 unidades de tal producto
  Como registro  este en el inventario  y ademas  si  se vente  por unidad como  manejarlo..


Si ese producto se vende por caja o por unidad yo llevaría el control unitario es decir.

COMPRA 10 cajas de 20 unidades (ENTRADA 10x20 = 200 piezas)

VENTA 1: 1 Caja (SALIDA 20 piezas)
VENTA 2: 5 piezas (SALIDA 5 piezas)

ENTRADAS 200 piezas
SALIDAS 25 piezas
EN INVENTARIO 175 piezas (175 div 20 = 8 cajas + 175 mod 20 = 15 piezas)

Digo, así lo haría yo

Saludos


  • 0

#4 Marc

Marc

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.484 mensajes
  • LocationMallorca

Escrito 18 mayo 2012 - 10:35

Hola.

Yo he añadido al albarán la columna "Stock_x_Unidades".

De manera que si una línea son dos cajas de 5 unidades, entonces en el albarán pongo 2 en Unidades y pongo 5 en Stock_x_Unidades. De esa forma el trigger que mantiene el stock ya sabe que tiene que incrementar el stock del producto en 2 * 5.

Saludos.
  • 0

#5 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.446 mensajes
  • LocationMéxico

Escrito 18 mayo 2012 - 10:42

No se que es albarán amigo Marc, pero supongo que es el catálogo de productos :)

En efecto, en ese catálogo debe existir dos conceptos, Caja y Pieza de X producto y dependiendo de los que se escoja se hace aritmética.

Saludos
  • 0

#6 enecumene

enecumene

    Webmaster

  • Administrador
  • 7.419 mensajes
  • LocationRepública Dominicana

Escrito 18 mayo 2012 - 11:33

El albarán es una especie de conduce, o sea, un documento de entrega de un pedido.

Saludos.
  • 0

#7 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 18 mayo 2012 - 02:33

El manejo de stock, y en particular en lo que es la problemática de las diferentes y posibles maneras de tratar las unidades de éste no es tan simple; involucra mucha metida de dedos y de mecanismos que desafían las reglas normales y teóricas de trabajar con lo que nos lleva a implementar variadas técnicas para tener la casa en orden.
Una posible solución podría ser añadir un campo Unidades como el que te ha sugerido, pero debe tenerse en cuenta bien hasta que punto es viable este enfoque.  ¿y si resulta que el producto x en realidad viene en diferentes tamaños y por tanto tanto contiene diferentes unidades?  Por ejemplo: Bayaspirina forte 20 unidades, y Bayaspirina forte 10 unidades ¿Cómo lo hacemos aquí?

Para un diseño elemental y simple el primer pensamiento de todo DBA y Analista es hacer una asociación directa entre un artículo y un campo "cantidad" o "unidad". No siempre es bueno, con más razón si en realidad para un mismo producto lo podemos catalogar en función del tamaño, presentación (envase), cantidad de unidades, etc.
Debido a esto es que en realidad hay que comprender que es necesario desprender la asociación directa entre el artículo x y el manejo de stock (y cantidades) de cada posible combinación de {tamaño, presentación, unidades} Lo que nos lleva a que debemos llevar las cuentas para cada uno de los posibles valores de esta tercia.
Esto se soluciona añadiendo otras entidades (naturalmente con los campos necesarios), que relacionen a cada producto con las combinaciones, y ahora estas combinaciones con las tablas que cumplen el rol de control de stock.

Ahora bien, hay que recalcar otro peligro más, también relacionado con lo anterior, muchas veces se confunde al producto, con la descripción del producto. De allí que se pueda tener y saber la descripción e información de un producto pero sin nada de existencia. Si uno mantuviera en la misma instancia tanto la descripción como al producto real (en estock) entonces una venta total de éste nos llevaría a ¡perder la descripción del producto!  ;)

Saludos,
  • 0

#8 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.446 mensajes
  • LocationMéxico

Escrito 18 mayo 2012 - 03:24

Pero amigo, si un mismo producto tiene diferentes cantidades, se debería manejar con códigos diferentes, lo que yo haría es algo mas o menos así:

CLAVE = PR12320
DESC = Bayaspirina forte 20 unidades
PIEZAS = 20

CLAVE = PR12310
DESC = Bayaspirina forte 10 unidades
PIEZAS = 10

CLAVE = PR12301
DESC = Bayaspirina forte
PIEZAS = 1

En realidad hay dos productos la presentación de 20 y la presentación de 10 unidades, sólo agregaría la venta unitaria con otro código. Digo, no me gusta complicarme la vida.

Saludos

  • 0

#9 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 18 mayo 2012 - 05:03

Pues si amigo, entiendo tu diseño y sabemos que gracias a ese campo ID tenemos un "mismo" producto pero con diferentes código. Es una posibilidad y bastante empleada; más no la única.

En algunos lugares, y en ocasiones, uno debe llevar la distinción de un producto dada por la tercia {tamaño, presentación, unidades} (e incluso en ocasiones de otros más, por ejemplo fabricante, ya que catalogan sus productos de esta forma. Naturalmente implica un diseño más complejo pero les facilita identificar sus productos cuando son demasiados. Se hace casi un diseño árbol que permite búsquedas mucho más rápidas:

producto (tipo)
-> Marca
--> Presentación (botella, envase, pack, etc)
----> ...

Esto les permite hacer códigos escalares sin demasiados problemas, por ejemplo #1.0.0.0 bebidas, #1.1.0.0 bebidas coca cola, #1.1.1.0 bebibas coca cola 2,25 litros, #1.1.1.1 bebidas coca cola 2,25 litros retornable; #1.1.1.1.2 Bebidas coca cola 2.25 litros vidrio

Esto es para la definición del producto, luego en lo que hace al stock se apoya directamente en el código de barras. De modo que cada instancia de cada definición de producto es fácilmente identificable y trazable.

Para ciertos rubros es necesario disponer de mecanismos de trazabilidad.  ;)

Saludos,
  • 0

#10 egostar

egostar

    missing my father, I love my mother.

  • Administrador
  • 14.446 mensajes
  • LocationMéxico

Escrito 18 mayo 2012 - 09:47

Pues si amigo, entiendo tu diseño y sabemos que gracias a ese campo ID tenemos un "mismo" producto pero con diferentes código. Es una posibilidad y bastante empleada; más no la única.

En algunos lugares, y en ocasiones, uno debe llevar la distinción de un producto dada por la tercia {tamaño, presentación, unidades} (e incluso en ocasiones de otros más, por ejemplo fabricante, ya que catalogan sus productos de esta forma. Naturalmente implica un diseño más complejo pero les facilita identificar sus productos cuando son demasiados. Se hace casi un diseño árbol que permite búsquedas mucho más rápidas:

producto (tipo)
-> Marca
--> Presentación (botella, envase, pack, etc)
----> ...

Esto les permite hacer códigos escalares sin demasiados problemas, por ejemplo #1.0.0.0 bebidas, #1.1.0.0 bebidas coca cola, #1.1.1.0 bebibas coca cola 2,25 litros, #1.1.1.1 bebidas coca cola 2,25 litros retornable; #1.1.1.1.2 Bebidas coca cola 2.25 litros vidrio

Esto es para la definición del producto, luego en lo que hace al stock se apoya directamente en el código de barras. De modo que cada instancia de cada definición de producto es fácilmente identificable y trazable.

Para ciertos rubros es necesario disponer de mecanismos de trazabilidad.  ;)

Saludos,


Bueno, habría que preguntarle a nuestro amigo delphinario, las necesidades de su cliente, eso que comentas, pues sólo lo imagino en Wallmart y ese tipo de negocios, ojalá y así sea la magnitud del cliente de nuestro amigo, pero si no, no hay que complicarse las cosas tanto.

Digo, no se :)

Saludos
  • 0

#11 delphinario

delphinario

    Advanced Member

  • Miembros
  • PipPipPip
  • 71 mensajes
  • LocationChile

Escrito 18 mayo 2012 - 10:34

Bueno  ya  de tremendas respuestas  ya me da miedo de tener  alguna  duda....
El sueño del pive es algo asi  como  un este Super..pero sin achicarme  ni agrandarme
creo que  en lo personal  no esta mal  ahy meterse en papa,  pero  el bolsillo  y el tiempo
dice  otra cosa.

Como sea    creo que por estos dias  se me  hachico la nuez y no puedo aun lograr    encontrar
el norte de esto.

  Es que    por  ejemplo en el caso de la  caja de aspirinas  , la caja en si  podria  tratarla como
  una solo unidad  de 20  pastillitas o pildoritas,  pero    si al  momento de vender  solo se vende
  dos pildoritas de esa  caja ..como  lo trataria en el  inventario...creo que por ese lado va mi consulta......
  • 0

#12 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 19 mayo 2012 - 01:34

Bueno, habría que preguntarle a nuestro amigo delphinario, las necesidades de su cliente, eso que comentas, pues sólo lo imagino en Wallmart y ese tipo de negocios, ojalá y así sea la magnitud del cliente de nuestro amigo, pero si no, no hay que complicarse las cosas tanto.

Digo, no se :)

Saludos

Efectivamente, es necesario contar con una buena explicación de lo que que el cliente de delphinario realmente necesita.
Naturalmente las necesidades, las políticas de negocio, los procesos que se siguen en la empresa, tienen su impacto y de una u otra forma moldean y condicionan a la forma del sistema.
Puede que si sea necesario complicarse las cosas, precisamente por la duda inicial de delphinario es que expuse esto amigo: llamar la atención al proceso en como se lleva el control de stock.
En cuanto la necesidad del control de stock pasa de un artículo a las unidades de éste, es una señal de que se requiere de un control más estricto; o bien que se está intentando dedicar más esfuerzo a un control que no aporta demasiado.  ;)

La pregunta aquí es ¿En verdad se necesita tener un control tan exhaustivo como para anotar que se vende una pastilla?
Estas preguntas van a servir para descubrir la forma en como se va a llevar el control de inventario:
¿Las ventas pueden ser por unidades, por paquete o ambas?
¿Para un "mismo artículo" se tienen previstos diferentes tamaño, presentación, etc? ¿Para el personal que trabaja allí, e incluso para la dirección, cada instancia de estas combinaciones representa una misma entidad abstracta; o bien cada uno es considerado como propio e independiente? En mis ejemplos: Entidad: Bayaspirina Forte vs Instancias: Bayaspirina Forte 10 y 20.
¿Que es más importante, controlar el paquete o la unidad, o bien las unidades de cada paquete?
¿Cómo se llevaba el control antes? ¿Era a mano? ¿Tan intensivo?
¿Cuando se hace una reposición o pedido de más artículos, se hace por lote? A su vez, ¿Los artículos que se venden en el negocio o emprendimiento tienen o necesitan de un control de caducidad?

delphinario, no temas preguntar ni dudar.
La cuestión pasa por entender unas cuantas cosas diferentes pero relacionadas:
1) Diferenciar lo que es la descripción de un producto del producto en si mismo. Por ejemplo:
#12345 "Bayaspirina Forte" Bayer Comprimidos 20 100g
#12346 "Bayaspirina Forte" Bayer Comprimidos 20 100g
#12347 "Bayaspirina para niños" Bayercito gotas 1  50cm3
#12348 "Bayaspirina para niños" Bayercito gotas 1  50cm3

Supongamos que #xxxxx es el número de código de barras. Veamos a #12345 y #12346 o a #12347 y #12348 ¿Tenemos un producto repetido o 2 productos de lo mismo? Lo cierto es que tenemos en realidad 2 productos de lo mismo: 2 instancias de "Bayaspirina Forte" en comprimidos de 20 unidades que pesan 100g de la empresa Bayer. Esto es en realidad la Descripción de un producto. Entonces sabemos que para una descripción de un producto se esperan muchos productos.

Este es el 1er error que cometemos casi siempre cuando hablamos de productos, y ya verás que justamente es que hacer esta distinción y separación entre producto y descripción es muy saludable.
Ya podemos entender que, a nivel de base de datos tenemos 2 tablas:
DescripcionProducto - 1 --- M - Producto

En forma simple:

DescripcionProducto:
--------------------------
#IDDescProd
Descripcion
...

Producto:
------------
#IDProducto
* DescProdID // clave foránea a #IDDescProd

Ahora entramos a la siguientes cuestiones, y son las que nos perjudican y potencian los problemas:

2) ¿Usar la tabla Producto como la del manejo de stock o tener una propia para eso?
La primera reacción y en lo que primero que se piensa es que si en Producto se va registrando cada producto adquirido entonces sabemos el stock. Por tanto ¿porqué no disponer en ésta los campos necesarios para llevar las cuentas?

Pensemos ahora: ¿Que sucede si vendemos la caja completa de Bayaspirina #12346? Rápidamente decimos pues entonces nos queda en esta tabla de "stock" los otros 3:
#12345
#12347
#12348

Ajá... pues dígame ahora ¿a que venta lo hizo? ¡No puede! ¿Porqué? Porque si efectivamente eliminó este registro acaba de romper la asociación de dicho producto con la venta y no hay modo de saberlo.
Entonces no, no es deseable eliminar fisicamente este registro. La solución elemental es disponer de un campo "Vendido".

Ahora supongamos que en realidad no se vende la caja completa, sino justamente 5 unidades. Por lógica sabemos que nos tiene que quedar 15. Estas 15 se venderán en otro momento, todas juntas o sueltas... no lo sabemos. Entonces: un producto puede ser vendido parcial o totalmente en una o varias ventas. A su vez en una misma venta se pueden haber vendido más de un producto. Sabemos por estas afirmaciones que:
Productos - M ---- M - Ventas

Entonces necesitamos romper esta relación mucho a muchos. ¿Cuál crees que es la posible entidad intermedia que asocie a una instancia particular? La respuesta: DetalleVentas.
Una venta está compuesta por lineas de venta, también conocida como Detalle de ventas. En cada detalle queda asentado UN producto particular, con la cantidad vendida.
Productos - 1 ---- M - DetallesVenta - M ---- 1 - Ventas

¿La pregunta que nos debemos hacer aquí es? Si la cantidad vendida queda en el detalle, ¿entonces que va en Productos? La respuesta es ¡justamente la cantidad remanente! Entonces en esta tabla Productos se dispone de un campo que vaya llevando al cuenta de unidades.

Fíjate ahora que el concepto de unidades sirve incluso si se trata de algo indivisible, o unidad = 1; como un paquete. Al descontarse esta unidad queda en 0, por tanto "Vendido" pasa a ser true o verdadero.

Con el uso de los triggers se puede hacer que se vaya actualizando el valor de dicho campo.

3) Stock mínimo, máximos:
Todavía no hemos terminado... quedamos que en la tabla Productos vamos registrando cada artículo y manejamos las unidades de éste. Consultando en esta tabla podemos ver el stock en cada momento, cuantas cantidades de cada artículo hay... pero resulta ser que no sabemos si justamente esa cantidad nos es la adecuada para mantener nuestro negocio. En casi la mayoría de los emprendimientos se requiere de una cantidad mínima de artículos... sin esta el negocio se para. ¿Donde crees que es adecuado disponer de esta información? ¿Te parece bien en Productos?
¿Si? ¿No? ¿Estás seguro? ¿No vas a cambiar? ¿Que te parece si ponemos esa información en DescripcionProducto?

Si el campo StockMinimo estuviera en Productos, no nos sirve de nada porque en realidad se estaría duplicando la información en cada instancia de un mismo Producto. Por el momento para este modelo y propuesta simple, en DescripcionProducto puede venir bien.

4) ¿No se está llenando demasiado la tabla de Productos? Va a crecer demasiado...
Por supuesto, en efecto así como está el modelo nos dice que esta tabla no olvida nada... crece y crece... y nunca se borran registros.
¿Que podemos hacer para no tener que vivir llenando cientos, sino miles de registros ante una compra? ¿Podemos tener esta información "más resumida"?
O... por supuesto que si, el concepto del que estamos hablando ahora es el de lote. Un lote es un conjunto de un producto, en vez de registrar cada producto, registramos lotes. Y en éste tenemos la cantidad de productos, luego es posible ir detallando el stock por producto si es necesario. Aquí es necesario hacer un paréntesis: dependiendo del negocio, a veces es necesario tener registrado tanto al lote como a cada producto. Por ejemplo las farmacias tienen la obligación de tener un número de identificación de producto y lote.


Responde ahora: ¿El manejo de stock está únicamente en una tabla o está asociado y depende de varias?
Desde el comienzo dije: "Las tablas relacionadas con el stock". ¿Porqué? Porque el stock es una cosa que no es fija, no es constante... tiene vida. No basta una tabla para ingeniárselas mira como este paseo nos ha llevado por al menos 4 tablas.

Este análisis debe completarse. Sólo quiero demostrar que esto no es cosa de así porque así, sino que debe pensarse con mucha meticulosidad.
Aún no se ha tocado los temas de rotación, y reposición entre otros. Estos son temas más avanzados pero que deben discutirse a la luz de las necesidades reales y depende fuertemente de la naturaleza del negocio para poder terminar de evaluar el impacto del manejo de stock. Por ello lo dejo a que lo veas en su momento oportuno.

Lo anterior es sólo una propuesta y no debe verse como LA RESPUESTA. Téngase presente que en base de datos no hay un único DER que nos resuelva las papas. Cada uno tiene su visión, su propuesta, y cada una tiene sus pros y contras pero ninguna es mejor que otra... simplemente son diferentes.

Fíjate como algo que parece sencillo en realidad no lo es. Lección: el manejo de stock es tan difícil como en cuanto más puntilloso sea el control que se requiera. No hay nada de básico... hasta el más simple requiere de un merecido análisis.

Aquí no se han discutido los alcances y los efectos que traerá sobre el resto de las entidades, que los tendrá. Tener muy presente esto.

Saludos,
  • 0

#13 Marc

Marc

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.484 mensajes
  • LocationMallorca

Escrito 19 mayo 2012 - 04:29

Pero amigo, si un mismo producto tiene diferentes cantidades, se debería manejar con códigos diferentes, lo que yo haría es algo mas o menos así:

CLAVE = PR12320
DESC = Bayaspirina forte 20 unidades
PIEZAS = 20

CLAVE = PR12310
DESC = Bayaspirina forte 10 unidades
PIEZAS = 10

CLAVE = PR12301
DESC = Bayaspirina forte
PIEZAS = 1

En realidad hay dos productos la presentación de 20 y la presentación de 10 unidades, sólo agregaría la venta unitaria con otro código. Digo, no me gusta complicarme la vida.

Saludos


Esto está bien en un sistema de gestión de compra/venta, donde puedes tratar cada empaque como un producto distinto y te ahorras el problema.

Pero yo me he encontrado este problema en un sistema de producción agrícola, donde por ejemplo pueden comprar un mismo fertilizante en cajas de 8l. o en cajas de 5l. A ellos no les interesa saber cuantas cajas tienen de 8l o 5l, sino cuantos litros de ese fertilizante quedan en total en stock (puesto que el stock se consume en los cuadernos de campo de tratamientos, y allí se especifica en litros o fracciones de litro usados).

NOTA: Otro ejemplo en esa aplicación son productos que se compran por kilos (viene en esas unidades en las facturas de compra) y que tienen que almacenarse en el stock en litros (puesto que el consumo se hace en litros).

Como dice Delphius, hay que hablar con el cliente final para saber lo que realmente necesita.
  • 0

#14 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 19 mayo 2012 - 06:27

Efectivamente Marc,
Es fundamental disponer del patrón de medida. Esto influye en las formas de manejo de stock. En cementeras por ejemplo no se cuentan solamente las bolsas, sino que se registran los kilos como también los litros de agua.
Es habitual en esos negocios llevar un doble inventario: por un lado el de cantidades de bolsas y tipificado por sus características y por el otro basado en el kilaje. El problema muy particular de éstas es que mientras el stock en otros negocios tienden a ocupar muchos volúmenes, en cementeras se busca lo inverso: reducir y gastar lo menos posible de allí a que su inventario es mucho más bajo y ajustado ya que la producción no se puede almacenar... es de producir y consumir al instante.
Yo además recomiendo mucho la lectura de libros sobre teoría de sotck.

Saludos,
  • 0

#15 Wilson

Wilson

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.137 mensajes

Escrito 19 mayo 2012 - 07:03

Bueno  ya  de tremendas respuestas  ya me da miedo de tener  alguna  duda....
El sueño del pive es algo asi  como  un este Super..pero sin achicarme  ni agrandarme
creo que  en lo personal  no esta mal  ahy meterse en papa,  pero  el bolsillo  y el tiempo
dice  otra cosa.

Como sea    creo que por estos dias  se me  hachico la nuez y no puedo aun lograr    encontrar
el norte de esto.

  Es que    por  ejemplo en el caso de la  caja de aspirinas  , la caja en si  podria  tratarla como
  una solo unidad  de 20  pastillitas o pildoritas,  pero    si al  momento de vender  solo se vende
  dos pildoritas de esa  caja ..como  lo trataria en el  inventario...creo que por ese lado va mi consulta......


A ver mi amigo, la cosa no es tan dura como parece, te comento, yo desarrollé una aplicación para una panadería; los requerimientos eran más o menos así: Podría darse el caso de que compraran harina por toneladas y usar en una receta gramos, podrían comprar aceite por potes de 5 galones y utilizar 10 cm cúbicos en una receta; la aplicación incluye un módulo de producción que descarga la materia prima del inventario y a su vez carga a este el producto terminado, también incluye  módulo de compras, de facturación y por su puesto varios puntos de ventas que trabajan en red.

Yo implementé un diseño para que sirviera no solamente para la panadería sino para cualquier empresa que compre, produzca y venda cualquier cosa.

Inicialmente lo que hice fue crear dos tablas así:

FAMILIAS_MEDIDAS
ID_FAMILIA
FAMILIA (Por ejemplo: masa, volumen, longitud... más las que el usuario necesite)

UNIDADES_MEDIDAS
ID_UNIDAD
ID_FAMILIA (Apunta a la tabla familias)
UNIDAD (Por ejemplo: Gramos, litros..más las que el usuario necesite)
FACTOR_CONVERSION

Ahora bien, en el campo FAMILIA de la primera tabla guardamos las familias standart (masa, volumen, longitud) más las que el usuario pudiera necesitar, por ejemplo tu farmacia necesita comerciar cajas, sobres, pastillas, que podrían tener una masa o un volumen, pero no hacen clara referencia a una medida convencional, por lo tanto podrías crear una familia con un nombre arbitrario para manejarlas, para ilustrar el funcionamiento vamos a llamarla FAMILIA_FARMACIA.

Ahora en el campo UNIDAD de  la tabla UNIDADES_MEDIDAS almacenamos las unidades standrat (Gramos,litros,etc) más las que el usuario necesite, para nuestro ejemplo de la farmacia allí guardaríamos registros como CAJA, SOBRE, PASTILLA.

La idea es que el programa maneje internamente las cantidades que se compran, las que se usan en producción y las que se venden, en una unidad standart por familia, me explico, los productos cuya familia sea masa serán manejados por el programa como gramos, los que cuya familia se volumen serán manejados como centímetros cúbicos, los de la fa familia de longitud serán manejados como centímetros, y para nuestro ejemplo de FAMILIA_FARMACIA las manejaremos como PASTILLAS. El usuario tendrá total libertad de escoger la unidad que más le convenga para la entrada de datos siempre y cuando pertenezcan a la misma familia, obviamente el programa solo le permitirá escoger unidades de la misma familia. (Más adelante miraremos el diseño de la tabla productos para entender la idea).

Para lograr el cometido descrito en el párrafo anterior entra en juego el campo FACTOR_CONVERSION de la tabla UNIDADES_MEDIDAS, quizá es aquí en donde está el meollo del asunto, allí guardaremos  por cada unidad un número que al multiplicarlo por la cantidad de producto nos dará la cantidad en la unidad standart, por ejemplo el FACTOR_CONVERSION de la unidad Kilogramos será 1000 (mil),  el de una libra inglesa sera 453,6 - lo anterior es fácil de deducir  pues son los números que necesitamos para convertirlos a gramos; igual haremos con las unidades de volumen para convertirlas a centímetros cúbicos y con las de longitud para convertirlos a centímetros; para nuestro ejemplo específico determinaríamos cuantas pastillas tiene un sobre y cuantas una caja para establecer el factor de conversión.

Ahora la tabla PRODUCTOS a demás de los campos tradicionales de código, de categoría, etc,  para desarrollar la idea solo necesita conocer la familia, el manejo del stock es indiferente, podrías llevarlo en la misma tabla de productos, entonces quedaría básicamente así:

PRODUCTOS
ID_PRODUCTO
PRODUCTO
ID_FAMILIA
EXISTENCIAS

Ahora bien, en las diferentes tablas de detalles que involucran a los productos, por ejemplo: los detalles de compra, los detalles de producción y los detalles de ventas, al saber de que familia es el producto, el programa le permitirá entrar datos en cualquier unidad de dicha familia, por ejemplo se compran 2 sacos de harina por 50 kilos, entonces habremos creado una unidad de medida de nombre SACOS POR 50 KILOS cuya familia será MASA y cuyo factor de conversión sera 50000 (puesto que 50 kilos tienen 50000 gramos) entonces el programa al guardar este detalle simplemente usa un TRIGGER que va a la tabla de unidades extrae el factor de conversión, en este caso multiplicaría  2 sacos por 50000 guardando en el campo EXISTENCIAS el valor de 100000 gramos.

La tabla de detalles para compras, producción o ventas, básicamente sería así:
ID_DETALLE
ID_COMPRA /*  o id_produccion o id_venta
CANTIDAD
ID_PRODUCTO
ID_UNIDAD

Obviamente el programa solo permitirá ingresar ID_UNIDAD de la familia de unidades del producto.


Ahora bien, al querer recuperar el valor de existencias es muy sencillo mostrarlo en la unidad que el usuario desee utilizando nuevamente el factor de conversión con una sencilla fórmula matemática. Igual sucede con los precios es fácil calcularlos a partir del factor de conversión.

Un cordial saludo.

  • 0

#16 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 19 mayo 2012 - 09:27

Muy bien aportado Wilson el uso de los patrones de medidas.

Ahora discúlpame pero no termino de comprender un pequeño detalle menor. Entonces, ¿tu por ejemplo creas UNA sola familia para el manejo de patrones de medida de un negocio, y luego haces que los productos usen los patrones propios creados para dicha familia? Por ejemplo, como dices creas el patrón o unidad PASTILLAS que dices. Siguiendo con tu diseño se exige cierto factor de conversión.

Si ahora todos los productos que requieran dicha unidad PASTILLAS se ven asociados a este único factor de conversión estarás en serios aprietos. ¿Porqué? Porque hay cajas que tran 30, otras que traen 10, etc... cada producto requiere de su propio factor de conversión, aún cuando se estén contando en una supuesta misma "unidad" o patrón de medida, para hacer una correcta asociación entre 1 paquete y la cantidad de pastillas de éste. El error está en asumir que pastillas es una unidad única de medición cuando ésta depende efectivamente del producto al que se está asociando.

No es lo mismo 20 pastillas de Bayaspirina Forte cuya caja o paquete trae 30 y por tanto equivale a 20/30 caja o paquete, que 20 pastillas de Biletán cuya caja trae 40 y que equivale a 0,5 paquete.  ;)
El error está precisamente en haber usado el concepto de pastillas y desapegarlo del paquete.

Una posible solución es tener en todo caso las unidades PASTILLAS10, PASTILLAS20, PASTILLAS30, y asi tantas como se necesiten para que luego los productos que poseen 10, 20, 30, etc pastillas puedan asociarse respectivamente. Ahora entonces cada unidad PASTILLASX tendrá un factor de 1/X o X según como se quiera contar.

Saludos,
  • 0

#17 Wilson

Wilson

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.137 mensajes

Escrito 19 mayo 2012 - 10:45

Muy bien aportado Wilson el uso de los patrones de medidas.

Ahora discúlpame pero no termino de comprender un pequeño detalle menor. Entonces, ¿tu por ejemplo creas UNA sola familia para el manejo de patrones de medida de un negocio, y luego haces que los productos usen los patrones propios creados para dicha familia? Por ejemplo, como dices creas el patrón o unidad PASTILLAS que dices. Siguiendo con tu diseño se exige cierto factor de conversión.


Observa que el diseño permite crear cuantas familias sean necesarias para un mismo negocio, no se limita a una sola. Por defecto el programa debería incluir las familias convencionales de masa, volumen y longitud, todas con sus  unidades más usadas y sus factores de conversión respectivamente, es fácil que el usuario complete las que faltaren  o inclusive personalizar alguna (de las convencionales). El caso de la droguería es típico para crear nuevas familias no convencionales, tomemos nuevamente el ejemplo del medicamento "Pastilla Delphina", que viene en Cajas de 100 unidades, cajas de 50 unidades y en sobres de 10 unidades, la farmacia puede venderlas  por cajas de 100, de 50, por sobres o finalmente por pastilla. En consecuencia crearíamos una nueva FAMILIA  "FAMILIA DELPHINA" o "FAMILIA CAJA_100_50_SOBRE10" o el nombre que se nos ocurra, posteriormente crearíamos las unidades "CAJA POR  100", "CAJA POR 50", "SOBRE POR 10" y finalmente "PASTILLA", todas apuntando a la familia escogida, la unidad candidata para ser el estandar es "PASTILLA", podría ser cualquiera de las otras, pero es más cómodo y lógico escoger la de menor denominación posible que esté a la venta, por lo tanto los factores de conversión serían para: PASTILLA->1, -> SOBRE POR 10 -> 10, CAJA POR 50 -> 50  y CAJA POR 100-> 100, creo que hasta aquí todo está claro, ahora bien todos los productos que se ajusten al anterior patrón deberían apuntar su ID_FAMILIA a esta familia, aunque el diseño no impide que se cree un patrón (FAMILIA_MEDIDAS -- UNIDADES_MEDIDAS) por cada producto que requiera de una familia no convencional.


Ahora un tip por fuera de tu pregunta, supongamos que la droguería compra ácido bórico por sacos de 50 Kilos (masa) y lo quiere vender por tazas de 30 gramos, solo bastaría crear una unidad de nombre TAZA POR 30  que apunte a la familia de MASA cuyo Factor de Conversión sería 30.

Un cordial saludo
  • 0

#18 delphinario

delphinario

    Advanced Member

  • Miembros
  • PipPipPip
  • 71 mensajes
  • LocationChile

Escrito 19 mayo 2012 - 11:10

Podria decir  que  es muy gratificante  leer  respuestas y comentarios  de un tono  tan serio  y profundo  con que  se ha tocado este  tama  de tal humiled e propuesta  pero que  alparecer  tiene  su grado de importacia  a la hora deun buen  plantiemiento....Gracias  queridos colegas.


  Se me ocurren  alguna  frases al vuelo:
 
  - "Intencion  de Compra/Venta  en el tratamiento del producto"
  -"Reduccion a una minima  expresion"

      Si la intencion es comprar  una  caja  para luego  venderla como tal , el tratamiento que se dara es de  una
      unidad    completa, por lo que.
     
        Su inidad Base  sera            :  unidad
        Su Subunidad  sera            :  caja
        Su unidad por defecto sera  :  Caja   
        Su equivalencia  sera          : 12
        Su factor  sera                    : 12 
           
    Por lo  que al comprar una  caja de clavos  de este tipo  estare  comprando
    Factor X  unidad = Equivalencia
    12  x  1 caja  =  12 clavos      {lo que  en su unidad base  es corecto  : unidades  }

    Al vender    1  caja de clavos    estare  vendiendo
    factor x  unidad vendida=equivalencia
      12    x  1  caja  =  12  clalvos

    Si Ademas la intension es compra/venta  son  clavos  agranel  (poe kilos)  seria:
        Su inidad Base  sera            :  Gramos
        Su Subunidad  sera            :  KG
        Su unidad por defecto sera  :  KG   
        Su equivalencia  sera          :  1000
        Su factor  sera                    : 1000

    Si compro  10 kilos de clavos  :
    Factor  x  unidad =  unidad Equivalente
    1000    x  10    = 10.000

  Si  vendo    solo  1/2 kilo de clavos    (0,5)("esta  manera de expresion en la venta  no medeja muy contento")
    Factor x  unidad =unidad Equivalente
      1000  x 0,5      = 500 gramos
   

  Por lo que  la unidad  de base  la cual usare  como unidad    del stok  es  la minia  exprsion.
   
Luego  tendria    la siguientes  Tablas

    Bodega ------>Stock<-------Productos<-----unidades

  Donde en Tproductos  podria tener  los  siguientes campos
  unidad base(como fk)
  subunidad
  unidad por defecto
  equivalencia
  Factor

  donde en T:unidades  podria tener
  Codigo
  unidad

Entonces  quisiera ver  si estoy en el camino  correcto
 

   
  • 0

#19 Wilson

Wilson

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.137 mensajes

Escrito 20 mayo 2012 - 09:55

Otra manera muy sencilla de abordar el tema  sería no complicarse con las unidades de medida, ni siquiera es necesario tener un campo para eso, consideremos el siguiente ejemplo:

Tenemos la pastilla DELPHINA, la farmacia tiene la posibilidad de comprarla en las presentaciones de: Caja por 100, Caja por 50 o Caja por 10, el productor factura cada presentación con un código diferente, por lo tanto en nuestro sistema podríamos tratarlos como TRES productos diferentes (DELPHINA CAJA POR 100, DELPHINA CAJA POR 50 Y DELPHINA CAJA POR 10) , entonces propongo una tabla de PRODUCTOS con una estructura básica así:

PRODUCTOS

ID_RODUCTO
PRODUCTO
EXISTENCIAS

Más una tabla de detalles que llamaremos DESGLOSE así:

DESGLOSE

ID_PRODUCTO_ORIGEN  //Apunta a ID_PRODUCTO en PRODUCTOS
ID_PRODUCTO_DESTINO  //Apunta a ID_PRODUCTO en PRODUCTOS
CANTIDAD_DESGLOSE

Ahora bien, en  ID_PRODUCTO_ORIGEN almacenamos el ID del producto susceptible de desglosamiento, en ID_PRODUCTO_DESTINO almacenamos el ID del producto en que se convertirá el producto de origen y en CANTIDAD_DESGLOSE obviamente el factor de conversión.

Con este diseño es fácil a la hora de ingresar un nuevo producto asignar los diferentes productos en los que se puede desglosar más sus respectivos  factores de conversión.

Para nuestro ejemplo, requerimos crear un CUARTO producto simplemente DELPHINA PASTILLA, entonces lo asignaríamos como producto de destino  de desglose de los TRES anteriores con su respectivos factores de conversión.

Ahora cuando el empleado de la farmacia abra una caja de DELPHINA  por 50, deberá registrar en el sistema dicha acción, que a su vez disparará un procedimiento que recibe como parámetros la cantidad de cajas abiertas y el producto de origen, en respuesta el sistema le mostrará los posibles productos en los que se puede convertir, entonces el empleado escoge el producto de destino, finalmente el sistema descarga del inventario el  valor pasado por el parámetro CANTIDAD DE CAJAS en el producto de origen, y aumenta  las existencias del producto de destino con el valor de la multiplicación del parámetro  CANTIDAD DE CAJAS  por el factor de conversión.

De esta manera el empleado puede vender el producto tal y como está declarado ( en la presentación que desee) y los valores del inventario serán los correctos para cada presentación.

Un cordial saludo.

PD: Este diseño trabajaría sin problemas para un negocio que solamente compre y venda, para otro que involucre producción sería insuficiente, en ese caso trabajaría mejor el de las tablas de unidades.


  • 0

#20 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 20 mayo 2012 - 10:13

Hola.

Wilson, entiendo y comprendo que se pueden crear tantas familias como se quisieran. Es que me parece más "lioso" para el usuario tener que crear varias familias, me parece más adecuado que se dispongan en esta familia las medidas y los múltiplos.

delphinario, Vas bien, veo que ya le vas agarrando la mano a los conceptos.

Ahora si me lo permiten, para esclarecer más algo, a lo que se le llama familia se conoce como Sistema de Medidas, cada medida (sea de longitud, peso, etc) tiene un patrón base. Luego es que existen los múltiplos y submúltiplos. El término unidad puede traer confusión. De allí que en el sistema SI (Sistema Internacional de medidas) tengamos:
Medida de Longitud:
Patrón: (m) metro
mm (0,001) < cm (0,01) < dm (0,1) < m (1) < dam (10) < hm (100) < km (1000)

Medida de masa:
Patrón: (k) kilo
mg (0,000001) < cg (0,00001) < dg (0,0001) < g (0,001) < dag (0,01) < hg (0,1) < kg (1) < mag|ct (10) < q (100) < t (1000)


Medida de tiempo:
Patrón: (s) segundo
ms (0,001) < cs (0,01) < ds (0,1) < s (1) < das (10) < hs (100) < ks (1000)

En lo posible hay que guardar los datos expresados en el patrón base del SI. Solo una pequeña parte del planeta no siguen el SI, de hecho son tres países locos que no lo han adoptado como el sistema prioritario: Estados Unidos, Birmania y  Liberia.

Podría utilizarse si les resulta más manejable el sistema cgs que toma como patrones el centímetro, gramo y segundo.

Se podría alterar el sistema de familia que propone Wilson para aceptar cualquier patrón y almacene tantos múltiplos y submúltiplos adecuados y requiera. De este modo el usuario elige el patrón de medida que necesite, coloque el valor y establezca el (sub)múltiplo en que lo exprese y luego el sistema convierte todo al patrón.

Entonces es: Sistema - 1 --- M - Medidas - 1 ---- M - Multiplos

Luego el usuario si necesita de estas medidas esotéricos como PASTILLAS, CAJAS, etc. puede proponer el patrón con el que están acostumbrados a contar y creará tantos (sub)Múltiplos como quiera.

Por ejemplo para la medida CAJA_BAYASPIRINA podría tener:

pastilla (1/30) < Tableta (1/3) < Caja (1) < Paquete < (12)

Entonces el patrón es la caja, una tableta equivale a 1/3 de la caja (es decir hay 3 tabletas por caja), una pastilla corresponde a 1/30 de la caja (por tanto cada tableta tiene 10 pastillas) y un paquete contiene una docena de cajas.

Si vendo 2 tabletas, coloco en cantidad 2, indico que estoy utilizando el submúltiplo tableta y entonces el sistema automáticamente lleva todo al patrón caja: 2 x (1/3) = 2/3 =  0,666. Con lo que todavía no se ha terminado de vender un paquete.

Y así se pueden crear tantas medidas como se requieran. Puede refinarse el concepto y dejar que los múltiplos y submúltiplos de estas medidas definidas por el usuario estén definidas por el producto y se puede aprovechar la misma medida para diferentes productos que la usen:

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

Entonces ahora en TablaPesos se consignan los diferentes pesos o factores de conversión. Entonces se puede hacer que el submúltiplo Tableta valga (1/3) para Bayaspirinas, (1/4) para Biletán, etc.

Saludos,
  • 0




IP.Board spam blocked by CleanTalk.