Manejar Caducidad de productos

[darkerbyte]

Hola de Nuevo:

Q tal amigos. Pues sigo avanzando con el sistema de punto de venta y me he topado con el problema de manejar caducidad de los productos.
Ahi si no me doy idea de como manejarlas pues cada producto aunque tenga caducidad diferente, el codigo de barras o clave (primary key) es el mismo.
Me he dado cuenta que cada producto tiene lotes pero seria engorroso desde el punto de venta estar indicando a que lote corresponde el producto vendido.
Se necesita implementar algo mas rápido.

Tengo una Tabla llamada Productos con los campos (abreviadamente):
Clave, Descripción, Existencia y Precio
¿Como podría llevar los datos de las caducidades de los productos?

Gracias de antemano por su invaluable tiempo y sus ingeniosos consejos.

PD. No supe donde colocar el tema, espero haya cabido bien aqui.

[luisgutierrezb]

Bueno una idea puede ser especificar en la entrada al almacén la caducidad de los productos, así lo harías por todo el lote pero que te llega, es una idea para no modificar mucho

[ContraVeneno]

tendría que ser así como menciona Luis

Cuando en tu inventario, le des entrada a un producto, debes definir la fecha de caducidad.

[darkerbyte]

Gracias por el consejo.

Entonces en la tabla de entradas agregaré el campo "caducidad" de tipo datetime. Con eso cuando doy entrada a los productos llevo la fecha de caducidad. Sin embargo. Como voy descontarlos al momento de vender?
O si se necesita determinar los productos que ya caducaron? Tengo las fechas de los productos q ya caducaron, pero ¿Como se que aun los tengo en existencia o que ya los vendí?

Ahi es donde me estoy rompiendo la cabeza.

Agradeceré una vez mas sus sugerencias

[[AzidRain]]

No te compliques, no hay forma realmente operativa de hacer lo que quieres. Precisamente porque es casi imposible llevar el control de los lotes ya que los proveedores te pueden surtir producto de diferentes lotes. Ahí si el control tiene (y debe) recaer en los humanos. Te lo digo por experiencia, ni el líder mundial en autoservicios ha logrado esto.

[Casimiro Notevi]

Se puede hacer, aunque es complejo y lleva muchos controles que hay que cumplir a rajatabla, se trata de controlar las ubicaciones físicas del almacén y tener localizados siempre todos los artículos en todos los momentos, es decir, controlar cualquier movimiento que hagan los artículos desde que llegan al almacén, colocarlos en una ubicación, moverlos, recogerlos, preparar el packing list y darle salida con el transportista. Cada artículo debe estar controlado, es complejo porque depende de muchos factores. Y si se quiere llevar bien hay que ser muy estrictos con todos los procesos y tener a todos los trabajadores muy disciplinados para que no se "rompa la cadena" y se le pierda el control a los artículos.
Un buen programa de gestión de almacenes (SGA) hace todo eso y mucho más, pero no es fácil de implementar en "la vida real".
La gestión comercial que hemos hecho donde trabajo tiene el módulo de SGA para los clientes que lo necesiten y es realmente útil y lleva un control total de los almacenes.
Lo usamos para los clientes que necesitan una trazabilidad total de los artículos y saber en tiempo real dónde está cada uno de ellos.
Por supuesto, también controla la caducidad de los artículos y cuando se hace un pedido de cualquier artículo, el programa indica cuál hay que recoger y dónde está, indicándole al operario la ruta más corta o más rápida para recoger todos los artículos del pedido (estoy hablando de almacenes de varias hectáreas de superficie, donde es primordial no perder tiempo dando vueltas buscando un artículo).

[[fjcg02]]

Empezado por darkerbyte

Hola de Nuevo:

Q tal amigos. Pues sigo avanzando con el sistema de punto de venta y me he topado con el problema de manejar caducidad de los productos.
Ahi si no me doy idea de como manejarlas pues cada producto aunque tenga caducidad diferente, el codigo de barras o clave (primary key) es el mismo.
Me he dado cuenta que cada producto tiene lotes pero seria engorroso desde el punto de venta estar indicando a que lote corresponde el producto vendido.
Se necesita implementar algo mas rápido.

Tengo una Tabla llamada Productos con los campos (abreviadamente):
Clave, Descripción, Existencia y Precio
¿Como podría llevar los datos de las caducidades de los productos?

Gracias de antemano por su invaluable tiempo y sus ingeniosos consejos.

PD. No supe donde colocar el tema, espero haya cabido bien aqui.

Esta problemática no se puede automatizar.
Supongo que estás haciendo la aplicación para una tienda.
Puedes tener por ejemplo una lata de espárragos ( o de lo que sea ). Esta lata tiene una fecha de caducidad. Es imposible saber cual vendes. En el ticket pondrá lata de espárragos , cantidad y precio. Nada más. Habrá un proceso diario y manual en el que una persona de la tienda revise las baldas y retire aquellas latas que hayan caducado.
Si se comercializa algún producto tratado, se pueden utilizar códigos de barras que arrastren el código del artículo y el lote, de manera que te descuente de un lote determinado. En este caso sí puedes aprovecharte de que al manipular/preparar el artículo le pegues una etiqueta con el código de barras montado con código+lote, y con un lector de código de barras leer la etqiueta y alimentar los dos datos automáticamente.

Respecto a cómo almacenar esta información , no lo puedes hacer a nivel de artículo. Tendrás que preparar una tabla adicional en la que de cada movimiento de artículos ( recepción, movimiento entre almacenes, ventas, ... ) identifiques el lote del artículo. Aún así , como ya te he comentado, si se vende a pie de tienda no sabrás esa información, tendrás que hacer inventarios periódicos con la frecuencia que consideres necesaria.
Por supuesto, necesitarás saber la cantidad de cada lote en cada uno de tus almacenes, siempre y cuando sea multialmacén tu aplicación.
Habitualmente se suele marcar los artículos que llevarán gestión de lotes y cuales no para aplicar estas normas sólo a aquellos que aplique.

Espero que te sirva de ayuda, aunque estoy suponiendo muchas cosas. Este tema es bastante extenso, y depende de la problemática que quieras recoger funcionalmente en tu aplicación.

Un saludo
PD: será que estoy metido de lleno en un proyecto con esta problemática ?

[Osorio]

Imagino que debes tener una tabla donde tienes los movimientos de entrada y otra tabla donde tienes los movimientos de salida (o los dos movimientos en una tabla) pero ademas debes tener una tabla donde tienes las cantidades existentes en la cual debes tener en resumen (codigoarticulo, lote, fechavencimiento, cantidad).

Pues, esa tabla de "existencias" es la que debes consultar para saber los que tienes vencidos.

la consulta seria mas o menos.

Código SQL [-]
select *
from tablaexistencias
where fechaactual >= fechavencimiento

Espero haberte despejado un poco el panorama.

Saludos.

[[AzidRain]]

La solución de baja tecnología que he visto que usa cierta cadena muy grande a nivel mundial es bien simple. Su sistema solo registra la entrada de los artículos, no se controlan lotes ni nada de eso, lo que hacen físicamente es marcar las cajas del producto que están recibiendo con un código de 12 colores (1 para cada mes) y de acuerdo con este código van surtiendo o sacando a la venta las cajas más antiguas.

El proceso electrónico si bien es cierto que se puede implementar, requiere una disciplina casi militar por parte de los usuarios para utilizarlo y además tiene muchos eslabones débiles que en caso de que alguien se brinque una parte del proceso se echa a perder todo el control en cuestión de minutos.

[darkerbyte]

Amigos:

Una vez mas les agradezco por sus pertinentes consejos. Algo asi me suponia pero nada como la experiencia de ustedes para confirmar mis supocisiones.

Un gran saludo y la mejor de las suertes.

Empezado por AzidRain

La solución de baja tecnología que he visto que usa cierta cadena muy grande a nivel mundial es bien simple. Su sistema solo registra la entrada de los artículos, no se controlan lotes ni nada de eso, lo que hacen físicamente es marcar las cajas del producto que están recibiendo con un código de 12 colores (1 para cada mes) y de acuerdo con este código van surtiendo o sacando a la venta las cajas más antiguas.

El proceso electrónico si bien es cierto que se puede implementar, requiere una disciplina casi militar por parte de los usuarios para utilizarlo y además tiene muchos eslabones débiles que en caso de que alguien se brinque una parte del proceso se echa a perder todo el control en cuestión de minutos.

Esa idea esta genial, AzidRain. La voy a proponer a mi cliente

[fjcg02]
PD: será que estoy metido de lleno en un proyecto con esta problemática ?

Amigo, creo que somos marinos del mismo barco. Buena suerte y gracias por el consejo.

[[fjcg02]]

Empezado por darkerbyte

Esa idea esta genial, AzidRain. La voy a proponer a mi cliente

Eso es consultoría de negocio, no técnica. Por lo tanto, ya que le limpias la casa a tu cliente, intenta morderle un buen pellizco.
En definitiva, no te limites a ofreces sw para un sector. Si ya lo coneces y puedes ofrecer asesoría en ese sector, utilizalo como arma comercial y aprovechalo para amortizar la inversión en el desarrollo.

Suerte y un saludo

[[AzidRain]]

Así es mi estimado amigo fjcg02, en este negocio no hay que limitarse nomas a vender software sino a arreglarle sus problemas al cliente (con o sin nuestro software), con la experiencia uno va a agarrando golpes y se va familiarizando con lo que los clientes hacen. Por supuesto que este "know-how" no es gratis, pero la mayoría de las empresas ven con mucho mejores ojos a una empresa o desarrollador que no se limita a hacerle un programa "tal cual" sino que además le soluciona otros problemas adicionales.

Me permito compartirles algunas máximas según mi experiencia:

1.- Casi todas las empresas (clientes) siempre buscan evitar fugas de dinero. Entonces busca las debilidades no de tu sistema sino de como hacen su opreración y con esa información cubrelas con tu sistema.

2.- Los usuarios administrativos siempre piensan como "siempre lo han hecho". Trata de que tu sistema les cambie poco a su rutina y en su caso les ahorre tiempo sin tener que obligarlos a hacerlo de otra forma.

3.- Los usuarios no saben de tecnicismos. Desarrolla tu sistema de manera que sea facilmente instalable y operable por cualquier persona con un promedio de conocimientos informáticos.

4.-Sé humilde. No pretendas que tu software, por muy bueno que sea, controle la operación de tu cliente. Salvo que sea un cliente que inicia operaciones. Todos los clientes siempre buscarán cambiar lo menos posible la forma en como ya hacen las cosas.

5.- Rodeáte de otros profesionales: contadores (contables), administradores, ingenieros, doctores, etc. según el caso de cada desarrollo que hagas. Uno solamente tiene la habilidad de trasladar lo que un cliente quiere a un mero código, pero no sabemos que es todo lo que ese cliente podría obtener con nuestra ayuda.


Espero les sea de utilidad y les recuerdo, no se anuncien como meros desarrolladores, sino como consultores.

[darkerbyte]

Hola AzidRain.

Esta información vale oro. Gracias por compartirnos tu experiencia.

[[AzidRain]]

Favor que me haces...muchas gracias. No recuerdo si lo comenté alguna vez pero precisamente por darme cuenta de la realidad del negocio además de ser Ingeniero en Sistemas también soy Lic. en Admon. de Empresas, claro que esto último lo estudié "ya de viejo" pero me ha servido mucho y me ha abierto muchas puertas.

Con la experiencia he aprendido que el cliente no compra software ni desarrollos que se ven bonitos, compra cualquier cosa que le solucione su problema y además le prevenga de problemas futuros. Desgraciadamente cuando solo tenemos la visión a (perdón por las malas palabras) "Mi sistema es muy chingón porque usa tal o cual tecnología y se conecta mediante web y además tiene interface con wikilieaks y pues si te interesa tienes que ahora hacer tus operaciones de esta forma porque MI sistema así trabaja, y MI sistema es muy chingón."

MUchos clientes compran la idea pero al final terminan o bien frustrados o bien "encabronados" cuando alguien que no sabe de sistemas pero si de administración le dice: "Y porque no haces para esta operación este papelito y así evitas esto y esto"...

Ahi está la clave, el software "per se" no es la solución de nada, las corporaciones y empresas hacen que el software funcione de acuerdo a sus necesidades, si estás desarrollando pensado lo contrario estás perdido.

Por último comparto otra máxima extraída de mil reuniones con clientes:

Cliente: Se podrá hacer esto? El sistema me podría dar en la mano esto? Podría ser automático?
Respuesta: Todo se puede hacer, solo se requiere más tiempo. (En nuestro negocio en efecto el tiempo=dinero).

Moraleja: Nunca le digas a un cliente que le va a costar mas caro lo que pide, dile que te llevará más tiempo realizarlo. Al final es lo mismo pero no se sentirá agredido y lo comprenderá mejor.

[[fjcg02]]

Mi experiencia como comercial de ERP en los últimos dos años, me está permitiendo cerciorarme de que vender software es más un 'pulso' psicológico que una venta. Si lo ganas, acabarás vendiendo. Tened en cuenta que en la mayoría de las ocasiones, el cliente no tiene ni repajolera idea de tecnología, o si sabe un poco tiene tal lío que es mejor que no sepa nada. Porque quién de nosotros sabe todo de todas las áreas técnicas ? ( sistemas de BBDD, comunicaciones, NEGOCIO, ...).

Lo más importante son bajo mi punto de vista los siguientes aspectos:

1.- Habla su idioma, cambia de discurso dependiendo de a quién te dirijes. No es lo mismo hablar con el jefe de producción que con el director financiero. Utiliza su mismo lenguaje, no el técnico.
2.- Identifica sus debilidades o los puntos críticos que quieren resolver, y en la demostración que les ofrezcas, demuéstrales cómo lo soluciona tu producto/solución. Si rompes la barrera que os separa, notarás que será totalmente diferente la actitud del cliente.
3.- Muestra tu módulo de bussines intelligent o cuadro de mando, con información estadística de todo tipo. Sobre todo si el gerente y el director financiero tienen peso en la demo y en la decisión de compra. Que vean que pueden explotar fácilmente sus datos para poder tomar decisiones con datos contrastados y no con suposiciones.
3.- Demuestra cómo pueden ahorrar tiempos y sobre todo errores en sus procesos y circuitos.
4.- Si puedes demostrarles el ROI ( retorno de la inversión ) al instalar tu solución, mejor.
5.- Demuestra al cliente que de su negocio, el que más sabe es él. Haz que tus ideas se conviertan en suyas, y te lo has ganado.
6.- Tened en cuenta que muchas veces no saben lo que compran ( si ves media docena de soluciones, al final sólo recuerdas un par de detalles de cada una), por eso es importante demostrar conocimiento de su medio, porque de esa manera acabas ganando su confianza. Y por supuesto es importante mantenerla...
7.- No flojees aunque te cueste convencer al cliente. Si el cliente no te deja marchar, es que tienes algo que él quiere o le interesa.
8.-Por mucho que te cueste, aprende contabilidad. Al final, cualquier negocio es $$.
9.- Y por último, en algo en lo que no estoy de acuerdo con AzinRain. Si tu sistema además de ser bueno, tiene un interfaz agradable y permite cierta libertad al usuario, mejor.

Respecto a lo que comenta AzidRain, estoy de acuerdo al 99% .

Del punto 9 quiero aclarar que del tema que vendo, hay un tema que deja boquiabiertos a los clientes e incluso a técnicos que no lo conocen. El sistema permite en cada rejilla de la aplicación y para cada usuario, seleccionar los campos que se quieren ver, el orden, seleccionar agrupaciones, sumas, medias, conteos, ... de los campos que quiera, seleccionar colores de filas en base a valores ( mayor, igual, menor ) que el propio usuario define, y todo esto guardarlo con un nombre, para recuperar esa configuración cuando desee e incluso elegirla como configuración por defecto, de manera que se aplique cada vez que se abre el formulario que contiene esa rejilla. Además, se pueden guardar diferentes configuraciones para una misma rejilla, porque puede ser útil tener diferentes configuraciones , por ejemplo para los cobros , dependiendo de si vamos a generar remesas bancarias o vamos a reclamar cobros pendientes, o queremos ver lo cobrado por cliente. Este tema se puede reproducir fácilmente con quantum grid ( debo decir que el sistema no está desarrollado en Delphi ) teniendo claros los conceptos de los que hablo.

Si alguien necesita más información o consejos al respecto, que no dude en solicitarlos. Estaré encantado de ayudar a todos .... los que no me hagan competencia.

Un saludo