8 respuestas en este tema

[giulichajari]

Estaba pensando, no se si es muy infantil la pregunta(me siento miedoso de hacerla) de hecho en la universidad mucho no enseñan.

Para descontar el stock:

 

Si tengo 1 unidad en stock y la aplicacion es multiusuario, (puedo tener cientos de vendedores), lo correcto es descontar el stock cuando se agrega un articulo a la grilla por mas que el usuario no confirme la venta. De ultimo caso si no lo compra se suma el stock.

De esta forma cuando el vendedor A (de los cientos) agrega el producto y viene el vendedor B a vender el mismo producto, quedaran 0 unidades.

 

Porque en este momento lo que hago es descontarlo al imprimir la factura,al confirmar la venta, pero si 2 o mas vendedores hacen su factura con este producto, se producira un fallo quedara menos de 0 o debera disculparse con el cliente?

 

Y de que manera puedo tener una transaccion o bloqueo para cada registro de producto? para que se agregue de a uno a la vez?

[cram]

Giuli, ¿no serán compradores A y B?

No me parece infantil tu pregunta.

 

Supongo que deberá depender del motor de bases de datos y como maneje las transacciones y bloqueos.

Desde mi punto de vista me parece una idea muy buena la de descontar, pero deberías hacer en una transacción ajena a la de la venta y confirmarla, por lo que se te puede armar un lío tremendo.

Es decir, el stock se descuenta, pero deberás hacer COMMIT, pues de lo contrario otra transacción de venta no se enterará de la diferencia en el stock, pero si en algún caso debes hacer ROLLBACK de la transacción de venta, también deberás crear una nueva transacción de corrección del STOCK y hacer COMMIT.

Firebird, por ejemplo, permite lo que se llama READ UNCONMITTED (DIRTY READ), con lo que es posible ver una transacción generada como completada, sin ser esta la verdad completamente. Entonces, el stock será descontado, etc. y solo haciendo COMMIT, se plasmará en la base de datos, pero si otra transacción lee la tabla de stock por medio de READ UNCONMITED, verá el stock descontado.

 

Es teoría, jamás lo implementé, (te cuento por las dudas)

 

Espero que te sirva, saludos.

Editado por cram, 19 octubre 2015 - 05:49 .

[cram]

Perdón, respondí sin ver bien que estaba en MySQL.

[giulichajari]

Perdón, respondí sin ver bien que estaba en MySQL.

Eso no es problema amigo cram...

Muchas gracias por tu respuesta

[poliburro]

Aquí puedes agregar un concepto adicional que se llama "Apartar" Me explico...

 

En cuanto un vendedor agregar un artículo a la venta, lo descuentas del stock y lo pones en apartado, de esa manera los demás vendedores al revisar existencias podrán saber que hay n artículos y n apartados dando la oportunidad de que decidan esperar un poco para saber si se confirman las ventas.

 

Al generar la nota de compra, en ese momento eliminas el artículo del apartado y confirmas la operación de venta. Me parece que esto ayuda un poco en los procesos donde la mercancía puede no ser vendida al final.

[Agustin Ortu]

Primero que no creo que sea una pregunta infantil...

 

Yo creo que la propuesta del poli es la mas adecuada para todos los casos. Lamentablemente no la terminamos implementando en nuestro sistema porque hasta ahora nunca surgio la necesidad

 

Lo que hacemos hoy es ejecutar todo en el contexto de la transaccion que graba la factura es decir, la factura se va armando sobre objetos en memoria y se van viendo los totales, impuestos, etc. Pero hasta que no me des el ok no se decrementa el stock (y otras cosas mas)

 

El problema de que cada vez que cargan a la factura afectar el stock, me parece inviable porque tambien llevamos un registro historico de como se fue moviendo el stock, y para que eso funcione necesitamos poder identificar el comprobante, cosa que es imposible si no se grabo el comprobante (que id tiene???). 

 

Entonces, cuando se graba el comprobante, todo en el contexto de la transaccion

 

1. Grabar datos de cabecera de comprobante, aca se genera la llave artificial Id y tambien el generador asigna el numero de comprobante correspondiente

 

2. Grabar detalle del comprobante

 

3. Afectar stock

 

4. Generar registro de movimientos

 

Basicamente para el punto 2, 3 y 4 necesito el Id del comprobante, asi que no queda otra

 

Lo del poli lo habiamos tirado sobre la mesa como idea, seria un numero ficticio de lo que el otro puede llegar a vender pero, a ciencia cierta no sabes que pasa, si la venta se efectua, se vende mas, se vende menos, pero como indicador sirve. Yo no pondria una traba en base a este numero impidiendo vender porque "posiblemente, no haya stock"

[Agustin Ortu]

Otros sistemas funcionan de manera distinta, de tal modo, los vendedores mas que la factura en si cargan un "presupuesto" o "remito" en el cual no hay ningun control de stock, simplemente se carga. Despues hay un encargado que levanta ese comprobante, verifica el stock, y es el que realmente le da salida y lo convierte en factura finalmente. 

[Nikolas]

Es un tema complejo y hay varias formas de resolverlo pero lo mas importante es la politica de la empresa.

¿Por que?

Ej:

- en los supermercados, se ven simultanemante mismos productos y la venta es real ya que pasa por las cajas.

- en empresas de logista o similares, los pedidos reservan stock pero no descuentan de él, hasta que no se emite la factura. En este caso existe un proceso previo que verifica si la cantidad pedida es menor o igual a la existente. Como si esto fuera poco, la realidad es que alguna veces si factura sin stock real porque la mercaderia llega a ultima hora. Ahora bien, hay 2 posibilidades que "llegue" o "no". si llega, todo bien caso contrario como ya se facturo, salen boletas al reparto y vuelven con diferencias para generar sus NC.

En cuanto a la programacion y para el caso de vendedores, algo practico seria, tomar la cantidad real antes de cargar el pedido menos la sumatoria de los pedidos cargados, esto te da el disponible.

 

Para le caso de puntos de venta, yo uso un SP (storedprocedure) que toma el detalle de la factura y descuenta el stock si es FC (factura) o suma si es NC. (nota de credito)

 

Saludos.

[cram]

Quiero agregar algo a la solución del problema: tener en cuenta el entorno en el que se produce la venta. Como lo dice Nikolas.

Si la venta en en línea y se entrega la mercadería a domicilio, algo como sucede con las ventas de Amazon, etc. es una cosa, pero, si la venta sucede en una caja registradora, no hay motivos para hacerse problemas con el stock, ya que es un valor tácito. Es imposible que teniendo la mercadería en el "check-out" no haya.

En otras palabras, en la venta con cajas registradoras, el stock debe ser descontado al terminar la transacción y no importará en otra venta de caja este stock resultante.

 

Yo, lo que hago es más o menos como los pasos que describe Agustín, exactamente, como dice Él, no hay otra con la generación (Post-> generar el ID de venta) de la cabecera y que todo esté dentro de una misma transacción. En cuanto al stock, lo divido en dos tiempos, vendido y entregado, el stock se descuenta al ser vendido, pero no se marca como entregado hasta que se genere el remito correspondiente, claro que esto funciona para ferreterías, mueblerías y mayoristas, mas no tanto en mini o supermercados con cajas registradoras (pues no hay remito).

 

En definitiva el momento para descontar el stock, es precisamente cuando se contrae la responsabilidad de entregar el producto al comprador. Es decir, la venta.

Existen sitios de venota en línea por internet que muestran con una barra de color cuando escacea el stock, normalmente va de rojo a verde (menos a más).

El asunto del stock no es sencillo y es un estudio aparte en toda la política de la empresa, ya que existe lo que se llama quiebre de stock, costo de mantener stock, entre otras cosas. Por eso es conveniente tener un seguimiento de las rotaciones de cada producto.

 

Me parece una buena solución la que describe Agustín, marcar la cantidad de artículos que pueden salir al ser vendidos eventualmente, pero cuya transacción aun no se ha concretado.

 

Saludos.