Descontar Stock en linea o en lotes

[ZeRoberto]

Con los DBF's yo descontaba el stock en linea osea agregaba un item
ponia la cantidad y automaticamente me descontaba el stock luego si
eliminaba el item restablecia el item.

Pero ahora estoy trabajando con MySQL y no se si hacerlo de la misma
forma o descontar al final en un proceso por lotes usando
transacciones.

Que me recomiendan?

Saludos

[Walter R. Ojeda Valiente]

Yo no te entendí, si puedes ser más explícito.

Saludos.

Walter.

> Date: Tue, 15 May 2012 14:10:43 -0500
> Subject: [vfp] Descontar Stock en linea o en lotes
> From: zero...@gmail.com
> To: publice...@googlegroups.com

[ZeRoberto]

Hola Walter

Osea tengo un formulario de punto de venta, cada vez que agrego un
item (producto) a mi lista de venta, descuento el stock
automaticamente de mi tabla de productos, y si el cliente decide no
comprar lo borro y el stock se restaura, esto lo hacia cuando usaba
los DBF's.

Ahora que uso MySQL no se si seguir con lo mismo, o solo actualizar
stock una vez que se confirme la venta osea al momento de darle F5
guardar, recorre todo los items y va descontando el stock por cada
producto.

Saludos

El 15/05/12, Walter R. Ojeda Valiente <wr...@hotmail.com> escribió:

[Walter R. Ojeda Valiente]

Si desde varias computadoras se puede vender un producto entonces lo mejor sería que en el momento de cargar la venta (aunque aún no se la haya grabado) lo descuentes del stock. Si luego por "H" o "B" motivo la venta no se realiza, entonces vuelves a aumentar el stock de ese producto. En Firebird eso se haría automáticamente con el ROLLBACK, no recuerdo el caso de MySQL.

De todas maneras, si usas un motor SQL no necesitas guardar en una columna de una tabla el stock actual de cada producto ya que cuando necesites conocer el stock actual simplemente haces un SELECT, el cual es muy rápido y muchísimo más seguro ya que la información que te mostrará será siempre la correcta.

Saludos.

Walter.

> Date: Tue, 15 May 2012 14:32:06 -0500
> Subject: Re: [vfp] Descontar Stock en linea o en lotes

[ZeRoberto]

Si!

Con los dbf lo menejo asi una vez que el producto se añada al carrito,
lo descuento del stock para evitar que otro vendedor lo comprometa y
me quede sin producto.

[Hector R. De los Santos]

Usando DBF's o algun motor no te recomendaria ese metodo.

Estarias rebajando de inventario sin que el proceso se realice , si es en varias computadoras que tienes ese punto de venta y haces una rebaja cuando agregas productos al detalle de la factura y desde otra terminal quieren vender de ese producto veran una existencia irreal porque el producto en la otra termianl no esta facturado aun y el cliente puede decidir no llevarselo.
Normalmente lo que hago es:
1) Valido la existencia  (que la cantidad sea mayor que cero)
2) Rebajo de Inventario
3) Guardo la factura

Lo de rebajar de inventario y guardar la factura lo hago dentro de un SP (en PostgreSQL todo lo que pones dentro de un SP estara dentro de una transaccion, osea que se realiza todo o no se hace nada)
En tu caso que usas MySQL, tambien lo puedes hacer dentro de un SP o una transaccion.

Suerte!


:: HDS Consultores TI
Servidores | Redes | Programacion | GNU/Linux | PostgreSQL
Web: http://hdsconsultores.net
Blog: http://codigohds.com
Linux User #:320363

[Walter R. Ojeda Valiente]

La analogía es la siguiente:
- En la góndola de un supermercado (el mueble donde se encuentran los productos en venta) hay 12 frascos (o potes) de dulce de naranja
- Un cliente extrae uno de esos frascos de dulce de naranja de la góndola y lo pone en su carrito
- Por lo tanto, en la góndola quedan 11 frascos de dulce de naranja
- Se acerca otro cliente ¿cuántos frascos de dulce de naranja ve que hay en la góndola? Evidentemente, 11
- La venta del dulce de naranja al primer cliente aún no se ha realizado pues aún no ha pasado por la Caja para pagar la compra
- Sin embargo, para todos los efectos desde el punto de vista de los demás clientes hay solamente 11 frascos de dulce de naranja disponibles
- Si el primer cliente por algún motivo (por ejemplo, por no tener suficiente dinero) decide no comprar el frasco de dulce de naranja entonces éste volverá a la góndola donde nuevamente habrá 12 frascos

Por lo tanto, en un programa de computadora debes simular esa situación descargando del stock el producto en el momento en que se lo registra. Si más tarde la venta no se realiza por algún motivo, vuelves a aumentar el stock de ese producto.

Si no lo hicieras así, un cliente podría decirte: "quiero comprar 12 frascos de dulce de naranja" y tú se los facturarías creyendo que tienes los 12 frascos siendo que en realidad solamente tienes 11 porque uno de ellos está en el carrito de otro cliente.

Saludos.

Walter.

---

Date: Tue, 15 May 2012 15:52:24 -0400

Subject: Re: [vfp] Descontar Stock en linea o en lotes

From: zah...@gmail.com
To: publice...@googlegroups.com

[mpulla]

Hola Walter.

Muy buen ejemplo.

En los cajeros del Súper he visto varios frascos de dulce de naranja que no se facturan y se quedan ahi un buen tiempo antes de ir nuevamente a la góndola.

Hay varias formas para actualizar el stock todas con sus pros y contras.

En mi caso me apego más a lo que hace Héctor.

Trabajo con Sql Server para mantener el stock utilizo una vista indexada que hace el trabajo, para no tener negativos lo hago mediante trigger

Saludos.
Mauricio

[Jairo]

Para agregar un poco al comentario de Walter,  en Zona libre de Colon aquí en Panamá se trabaja casi igual llamándose la mercancía que el cliente escoge como mercancía reservada.. o separada, el asunto es que hasta que no se cancele la factura no se saca de inventario es decir , va a una columna de mercancía RESERVADA pero se muestra el  en el kardex , que al sacar un informe o consulta de inventario se muestra la cantidad de la mercancía reservada , cantidad en bodega  que es la reservada menos la existencia real   y una columna del total.     

 

Cuando el cliente tiene la mercancía  es decir se le envió, aunque no la haya pagado ya se descarga de inventario .

 

JM

[Hector R. De los Santos]

@Walter,

Es buen ejemplo, pero aun haci no lo veo recomendable, es mi opinion.
Estas realizando un proceso que aun no se ha hecho, en caso que planteas:

"Si no lo hicieras así, un cliente podría decirte: "quiero comprar 12 frascos de dulce de naranja" y tú se los facturarías creyendo que tienes los 12 frascos siendo que en realidad solamente tienes 11 porque uno de ellos está en el carrito de otro cliente."

Se supone que el cliente debe ir con su carrito a buscar los 12 frascos no?
Esta claro que no vera los 12 frascos sino 11.

Por otra razon que no me gusta este modo es por el asunto de historial de movimientos, tendrias muchas entradas y salidas de almacen solo porque se agrego o se saco de la lista de items.
No se como trabajas esa parte, pero en el historial de movimientos, uno de los datos que guardo es el numero de documento, tipo y fecha. En este caso esos datos no los podria guardar porque no se genero con ese producto.

Simplemente no rebajo nada de almacen hasta que realmente un proceso no lo justifique. (Salvo algunos casos apartes, pero para mi este no es uno de ellos)

Para cualquier tipo de negocio que se dedique a la venta de productos es necesario un historial de movimientos por asuntos de regulacion y control.

@Jairo

Este metodo que planteas si es de mi agrado y el cual lo utilizo, donde se pueden hacer apartados de productos, pero aun siguen estando en almancen (porque estan apartados y no han sidos sacados fisicamente del almacen), por tal motivo se ven en los listados de stock y demas.

:: HDS Consultores TI
Servidores | Redes | Programacion | GNU/Linux | PostgreSQL
Web: http://hdsconsultores.net
Blog: http://codigohds.com
Linux User #:320363

[Walter R. Ojeda Valiente]

Es que estás hablando de dos cosas distintas:
- Por un lado, el stock de cada producto que se ve en las pantallas de cada computadora mientras se están realizando las ventas
- Por el otro lado, el historial de los movimientos

En el primer caso, la transacción puede confirmarse (con un COMMIT) o no (con un ROLLBACK)

En el segundo caso, solamente se muestran las transacciones confirmadas (con COMMIT)

Y con respecto al ejemplo del supermercado, un cliente puede llamar por teléfono y decir: "quiero 12 frascos de dulce de naranja", el usuario mira en su computadora, ve que hay 12 frascos, le factura, y luego se da cuenta que tu programa le mintió porque solamente había 11.

Y algo así podría suceder no solamente en un supermercado sino en muchísimos otros negocios, como farmacias, ventas de repuestos para vehículos, ventas de electrodomésticos, ventas de ropas, etc.

Para evitarte problemas, lo mejor es que cuando en una computadora se registró una venta se haga el descuento del stock, si luego la venta no se realizó por algún motivo entonces se hace el ROLLBACK y se repone el stock.

Saludos.

Walter.

---

Date: Tue, 15 May 2012 17:27:53 -0400

[Hector R. De los Santos]

Son simplemente dos modos de trabajar, el que utilizas y el que yo utilizo, eso de hacer ROLLBACK, COMMINT en insercciones de items simplemente no me gustan, me parecen cosas que se pueden evitar, en ese momento el producto sigue dentro, no ha salido. Para que sacarlo.
No se como trabajas el asunto del inventario, pero yo lo realizo con una sumatoria de entradas y salidas, eso de actualizar un campo para obtener la existencia actual tampoco me gusta, aunque me ha tocado trabajar con casos y los he implementado con triggers, pero aun haci con un historial de movimientos.

Me puedes mostrar varias justificaciones de tu modo de trabajar, si la utilizas es porque te ha dado resultados y a tus clientes les ha gustado, tambien hay que ver que tipo de negocio es y como es el comportamiento en las ventas.

Si me muestras 100 formas de porque lo haces, yo te mostrare 100 mas, son simplemente dos formas de trabajar, ahora hay que dejar que Roberto haga sus pruebas y decida.

:)

:: HDS Consultores TI
Servidores | Redes | Programacion | GNU/Linux | PostgreSQL
Web: http://hdsconsultores.net
Blog: http://codigohds.com
Linux User #:320363

[Walter R. Ojeda Valiente]

Para todos los efectos desde el punto de vista de los otros clientes ya ha salido. Solamente aún no se ha finalizado la transacción comercial, que es otra cosa. No confundas.

Tu forma de trabajar puede ser aceptable si tienes una, dos o tres computadoras y cada cajero está cerca de los demás cajeros y puede preguntarle: ¿estás vendiendo frascos de dulce de naranja?. Pero en una empresa grande, donde hay 20, 30, 40 ó más cajeros tal cosa es imposible. Además, no te olvides que los pedidos también pueden hacerse por teléfono, por fax, por e-mail, por celular o por página web.

¿Qué pasa si se reciben dos pedidos por teléfono, cada uno de ellos con un montón de ítems y no hay suficiente cantidad en stock para satisfacer ambos pedidos? Según tu método, recién en el momento de hacer click sobre el botón "Grabar" el segundo usuario sabrá que no puede vender un ítem, que está segundo o tercero en una lista de 15. Entonces tiene que llamarle al cliente y decirle: "lo siento mucho, el producto XXX no te lo podré vender porque ahora recién mi programa me avisa que no tengo tanta cantidad en stock. Cuando me estabas dictando lo que necesitabas me dijo que tenía suficiente cantidad pero ahora me dice que no".

Hmmmmmmmmmm, a mí particularmente no me gusta esa situación, ya que ni el usuario ni el cliente del usuario quedarán muy conformes. No sé que ventajas tienes al descontar del stock solamente después del COMMIT, espero que me digas alguna.

Y como ya dije anteriormente, actualizar una columna para saber la cantidad actual en stock de un producto no es recomendable en SQL, sí es aceptable en .DBF

Saludos.

Walter.

---

Date: Tue, 15 May 2012 18:02:47 -0400

[Programas ToP]

Cómo manejan que la factura no se complete por alguna razón y los items ya están descargados los items del stock?
Que no se descuente por ejemplo porque se apagó la terminal, se bloqueó, cayó el servidor, etc.

Saludos cordiales

Manuel Tovar Ruiz
Barranquilla - COLOMBIA

Antes de imprimir este correo piensa en la contribución que puedes hacer al medio ambiente.
Please consider your environmental responsibility and commitment before printing.

[Walter R. Ojeda Valiente]

Los ítems se descuentan pero no se confirman hasta que se hace el COMMIT correspondiente.

O sea que si la transacción termina con un ROLLBACK o porque cayó el Servidor entonces esos ítems retornan al stock y todos contentos.

Saludos.

Walter.

---

Date: Tue, 15 May 2012 17:48:28 -0500
From: progra...@gmail.com
To: publice...@googlegroups.com

[Programas ToP]

Osea que desde el primer item arranca un START TRANSACTION? y cuando termina la factura hace un COMMIT?
Estamos hablando de un escenario con un motor de BD o con tablas nativas?

Saludos cordiales

Manuel Tovar Ruiz
Barranquilla - COLOMBIA

Antes de imprimir este correo piensa en la contribución que puedes hacer al medio ambiente.
Please consider your environmental responsibility and commitment before printing.

[Walter R. Ojeda Valiente]

Yo estoy hablando de SQL (Firebird, especificamente) y supongo que Héctor también pues él dice que usa Postgre.

Exactamente, con el primer ítem ya hay un START TRANSACTION que finaliza con un ROLLBACK si la venta no se realizó por algún motivo (aumentando por lo tanto nuevamente la cantidad en stock de cada producto) o con un COMMIT (en cuyo caso, la cantidad descontada simplemente se confirma y queda descontada).

El algoritmo sería el siguiente:

START TRANSACTION
  - Descontar del stock
  - Descontar del stock
  - Descontar del stock
Si COMMIT
  Nada, está todo OK
Fin si
Si ROLLBACK
   - Aumentar el stock de cada producto (lo cual se realiza automáticamente)
Fin si

Al llegar a esta línea siempre tienes tu stock correcto.

Debo aclarar que las transacciones en Firebird tienen 4 niveles de aislamiento, la que se debe usar para lo anteriormente expuesto es la READ UNCOMMITED.

Saludos.

Walter.

---

Date: Tue, 15 May 2012 17:54:41 -0500

[Guillermo MDQ]

Walter, una duda,  al comenzar el START TRANSACTION ya en la base de datos se descuenta el stock, y queda visible ese descuento desde otros equipos ?
Yo crei que se necesitaba el COMMIT para que quedara grabado y se reflejara en  la B de Datos.

Saludos
Guillermo

El martes, 15 de mayo de 2012 20:09:57 UTC-3, Walter R. Ojeda Valiente escribió:

Yo estoy hablando de SQL (Firebird, especificamente) y supongo que Héctor también pues él dice que usa Postgre.

Exactamente, con el primer ítem ya hay un START TRANSACTION que finaliza con un ROLLBACK si la venta no se realizó por algún motivo (aumentando por lo tanto nuevamente la cantidad en stock de cada producto) o con un COMMIT (en cuyo caso, la cantidad descontada simplemente se confirma y queda descontada).

El algoritmo sería el siguiente:

START TRANSACTION
  - Descontar del stock
  - Descontar del stock
  - Descontar del stock
Si COMMIT
  Nada, está todo OK
Fin si
Si ROLLBACK
   - Aumentar el stock de cada producto (lo cual se realiza automáticamente)
Fin si

Al llegar a esta línea siempre tienes tu stock correcto.

Debo aclarar que las transacciones en Firebird tienen 4 niveles de aislamiento, la que se debe usar para lo anteriormente expuesto es la READ UNCOMMITED.

Saludos.

Walter.

---

Date: Tue, 15 May 2012 17:54:41 -0500
From: progra...@gmail.com

To: publicesvfoxpro@googlegroups.com

Subject: Re: [vfp] Descontar Stock en linea o en lotes

Osea que desde el primer item arranca un START TRANSACTION? y cuando termina la factura hace un COMMIT?
Estamos hablando de un escenario con un motor de BD o con tablas nativas?

Saludos cordiales

Manuel Tovar Ruiz
Barranquilla - COLOMBIA

Antes de imprimir este correo piensa en la contribución que puedes hacer al medio ambiente.
Please consider your environmental responsibility and commitment before printing.

El 15/05/2012 05:53 p.m., Walter R. Ojeda Valiente escribió:

Los ítems se descuentan pero no se confirman hasta que se hace el COMMIT correspondiente.

O sea que si la transacción termina con un ROLLBACK o porque cayó el Servidor entonces esos ítems retornan al stock y todos contentos.

Saludos.

Walter.

---

Date: Tue, 15 May 2012 17:48:28 -0500
From: progra...@gmail.com

To: publicesvfoxpro@googlegroups.com

Subject: Re: [vfp] Descontar Stock en linea o en lotes

Cómo manejan que la factura no se complete por alguna razón y los items ya están descargados los items del stock?
Que no se descuente por ejemplo porque se apagó la terminal, se bloqueó, cayó el servidor, etc.

Saludos cordiales

Manuel Tovar Ruiz
Barranquilla - COLOMBIA

Antes de imprimir este correo piensa en la contribución que puedes hacer al medio ambiente.
Please consider your environmental responsibility and commitment before printing.

El 15/05/2012 05:44 p.m., Walter R. Ojeda Valiente escribió:

Para todos los efectos desde el punto de vista de los otros clientes ya ha salido. Solamente aún no se ha finalizado la transacción comercial, que es otra cosa. No confundas.

Tu forma de trabajar puede ser aceptable si tienes una, dos o tres computadoras y cada cajero está cerca de los demás cajeros y puede preguntarle: ¿estás vendiendo frascos de dulce de naranja?. Pero en una empresa grande, donde hay 20, 30, 40 ó más cajeros tal cosa es imposible. Además, no te olvides que los pedidos también pueden hacerse por teléfono, por fax, por e-mail, por celular o por página web.

¿Qué pasa si se reciben dos pedidos por teléfono, cada uno de ellos con un montón de ítems y no hay suficiente cantidad en stock para satisfacer ambos pedidos? Según tu método, recién en el momento de hacer click sobre el botón "Grabar" el segundo usuario sabrá que no puede vender un ítem, que está segundo o tercero en una lista de 15. Entonces tiene que llamarle al cliente y decirle: "lo siento mucho, el producto XXX no te lo podré vender porque ahora recién mi programa me avisa que no tengo tanta cantidad en stock. Cuando me estabas dictando lo que necesitabas me dijo que tenía suficiente cantidad pero ahora me dice que no".

Hmmmmmmmmmm, a mí particularmente no me gusta esa situación, ya que ni el usuario ni el cliente del usuario quedarán muy conformes. No sé que ventajas tienes al descontar del stock solamente después del COMMIT, espero que me digas alguna.

Y como ya dije anteriormente, actualizar una columna para saber la cantidad actual en stock de un producto no es recomendable en SQL, sí es aceptable en .DBF

Saludos.

Walter.

---

Date: Tue, 15 May 2012 18:02:47 -0400
Subject: Re: [vfp] Descontar Stock en linea o en lotes
From: zah...@gmail.com

To: publicesvfoxpro@googlegroups.com

To: publicesvfoxpro@googlegroups.com

To: publicesvfoxpro@googlegroups.com

> >> To: publicesvfoxpro@googlegroups.com

[Walter R. Ojeda Valiente]

Otra forma de resolverlo es usando una tabla auxiliar que tenga solamente dos columnas:
- Identificador del producto
- Cantidad vendida (pero no confirmada todavía)

A esta tabla se le insertan o se le eliminan filas y se le actualizan las cantidades.

- Hay 12 frascos de dulce de naranja
- Se registra la venta de un frasco. Por lo tanto en la tabla auxiliar se inserta (o actualiza) la fila de dulce de naranja, con cantidad_no_confirmada = cantidad_no_confirmada + 1 (porque se vendió un frasco)
- Si se quiere saber cuantos frascos de dulce de naranja hay actualmente disponibles para la venta, se suman las entradas "commiteadas", se restan las salidas "commiteadas" y también se restan las cantidades_no_confirmadas
- Cuando finaliza la transacción se hace la resta: cantidad_no_confirmada = cantidad_no_confirmada - cantidad_vendida

Saludos.

Walter.

---

From: wr...@hotmail.com
To: publice...@googlegroups.com
Subject: RE: [vfp] Descontar Stock en linea o en lotes
Date: Tue, 15 May 2012 23:09:57 +0000

[Walter R. Ojeda Valiente]

Hola Guillermo

Eso depende del tipo de transacción y también acabo de publicar otra alternativa.

Saludos.

Walter.

---

Date: Tue, 15 May 2012 16:34:27 -0700
From: gol...@gmail.com
To: publice...@googlegroups.com

[Programas ToP]

En MySQL que es el motor que utilizo y conozco, mientras no se hace COMMIT no se refleja en otro SELECT.
El objetivo de las TRANSACCIONES en motores de BD es poder mantener la integridad y consistencia de la información: actualizo todo o nada
para que no haya inconsistencias de movimientos de inventario sin factura por ejemplo.

El tema de stock en línea creo que es diferente y se sale un poco del START TRANSACTION y el COMMIT

Saludos cordiales

Manuel Tovar Ruiz
Barranquilla - COLOMBIA

Antes de imprimir este correo piensa en la contribución que puedes hacer al medio ambiente.
Please consider your environmental responsibility and commitment before printing.

[Guillermo MDQ]

Esta ultima alternativa me resulta mas logica.
El tipo de transaccion que indicaste antes es exclusiva de Firebird o funciona en todas las demas bases de datos ?

Saludos
Guillermo

El martes, 15 de mayo de 2012 20:39:54 UTC-3, Walter R. Ojeda Valiente escribió:

Hola Guillermo

Eso depende del tipo de transacción y también acabo de publicar otra alternativa.

Saludos.

Walter.

---

Date: Tue, 15 May 2012 16:34:27 -0700
From: gol...@gmail.com

[Walter R. Ojeda Valiente]

Es que no estás actualizando todavía, eso solamente lo hace el COMMIT, lo que puedes hacer es que los cambios realizados dentro de una transacción sean visibles a otras transacciones (o no, dependiendo del contexto).

En muchos casos, tal aprovechamiento es inaceptable y en otros, es el más adecuado.

Saludos.

Walter.

---

Date: Tue, 15 May 2012 18:44:57 -0500
From: progra...@gmail.com

[Walter R. Ojeda Valiente]

Está en el estandar SQL pero no todos los motores lo implementan.

Saludos.

Walter.

---

Date: Tue, 15 May 2012 16:48:17 -0700
From: gol...@gmail.com
To: publice...@googlegroups.com

[Hugo C.]

Interesante el debate.

Saludos.

On 15 mayo, 17:39, "Walter R. Ojeda Valiente" <w...@hotmail.com>
wrote:

> Hola Guillermo
>
> Eso depende del tipo de transacción y también acabo de publicar otra alternativa.
>
> Saludos.
>
> Walter.
>

> Date: Tue, 15 May 2012 16:34:27 -0700

> From: gols...@gmail.com

> To: publice...@googlegroups.com
> Subject: Re: [vfp] Descontar Stock en linea o en lotes
>
> Walter, una duda,  al comenzar el START TRANSACTION ya en la base de datos se descuenta el stock, y queda visible ese descuento desde otros equipos ?
> Yo crei que se necesitaba el COMMIT para que quedara grabado y se reflejara en  la B de Datos.
>
> Saludos
> Guillermo
>
> El martes, 15 de mayo de 2012 20:09:57 UTC-3, Walter R. Ojeda Valiente  escribió:
>
> Yo estoy hablando de SQL (Firebird, especificamente) y supongo que Héctor también pues él dice que usa Postgre.
>
> Exactamente, con el primer ítem ya hay un START TRANSACTION que finaliza con un ROLLBACK si la venta no se realizó por algún motivo (aumentando por lo tanto nuevamente la cantidad en stock de cada producto) o con un COMMIT (en cuyo caso, la cantidad descontada simplemente se confirma y queda descontada).
>
> El algoritmo sería el siguiente:
>
> START TRANSACTION
>   - Descontar del stock
>   - Descontar del stock
>   - Descontar del stock
> Si COMMIT
>   Nada, está todo OK
> Fin si
> Si ROLLBACK
>    - Aumentar el stock de cada producto (lo cual se realiza automáticamente)
> Fin si
>
> Al llegar a esta línea siempre tienes tu stock correcto.
>
> Debo aclarar que las transacciones en Firebird tienen 4 niveles de aislamiento, la que se debe usar para lo anteriormente expuesto es la READ UNCOMMITED.
>
> Saludos.
>
> Walter.
>

> Date: Tue, 15 May 2012 17:54:41 -0500

> From: programas...@gmail.com

> To: publice...@googlegroups.com
> Subject: Re: [vfp] Descontar Stock en linea o en lotes
>

>     Osea que desde el primer item arranca un START TRANSACTION? y cuando
>     termina la factura hace un COMMIT?
>
>     Estamos hablando de un escenario con un motor de BD o con tablas
>     nativas?
>
>     Saludos cordiales
>
> Manuel Tovar Ruiz
> Barranquilla - COLOMBIA
>
> Antes de imprimir este correo piensa en la contribución que puedes hacer al medio ambiente.
> Please consider your environmental responsibility and commitment before printing.
>
>     El 15/05/2012 05:53 p.m., Walter R. Ojeda Valiente escribió:
>
>         Los ítems se descuentan pero no se confirman hasta que se hace
>         el COMMIT correspondiente.
>
>         O sea que si la transacción termina con un ROLLBACK o porque
>         cayó el Servidor entonces esos ítems retornan al stock y todos
>         contentos.
>
>         Saludos.
>
>         Walter.
>

>           Date: Tue, 15 May 2012 17:48:28 -0500
>

>           From: programas...@gmail.com
>
>           To: publice...@googlegroups.com
>
>           Subject: Re: [vfp] Descontar Stock en linea o en lotes
>

>                 Date: Tue, 15 May 2012 18:02:47
>                 -0400
>
>                 Subject: Re: [vfp] Descontar Stock en linea o en lotes
>
>                 From: zah...@gmail.com
>

>                 To: publice...@googlegroups.com

>                   Walter R. Ojeda Valiente <w...@hotmail.com>

> ...
>
> leer más »

[Guillermo MDQ]

Si, esta muy bueno conocer las distintas alternativas.
Yo soy de los que prefiero que no se grabe nada hasta que todo este confirmado, pero tambien es que no me ha pasado un caso como el comentado del supermercado.

Saludos
Guillermo

El martes, 15 de mayo de 2012 20:53:18 UTC-3, Hugo C. escribió:

Interesante el debate.

Saludos.

On 15 mayo, 17:39, "Walter R. Ojeda Valiente" <w...@hotmail.com>
wrote:
> Hola Guillermo
>
> Eso depende del tipo de transacción y también acabo de publicar otra alternativa.
>
> Saludos.
>
> Walter.
>
> Date: Tue, 15 May 2012 16:34:27 -0700
> From: gols...@gmail.com

> To: publicesvfoxpro@googlegroups.com

> To: publicesvfoxpro@googlegroups.com

> Subject: Re: [vfp] Descontar Stock en linea o en lotes
>
>     Osea que desde el primer item arranca un START TRANSACTION? y cuando
>     termina la factura hace un COMMIT?
>
>     Estamos hablando de un escenario con un motor de BD o con tablas
>     nativas?
>
>     Saludos cordiales
>
> Manuel Tovar Ruiz
> Barranquilla - COLOMBIA
>
> Antes de imprimir este correo piensa en la contribución que puedes hacer al medio ambiente.
> Please consider your environmental responsibility and commitment before printing.
>
>     El 15/05/2012 05:53 p.m., Walter R. Ojeda Valiente escribió:
>
>         Los ítems se descuentan pero no se confirman hasta que se hace
>         el COMMIT correspondiente.
>
>         O sea que si la transacción termina con un ROLLBACK o porque
>         cayó el Servidor entonces esos ítems retornan al stock y todos
>         contentos.
>
>         Saludos.
>
>         Walter.
>
>           Date: Tue, 15 May 2012 17:48:28 -0500
>
>           From: programas...@gmail.com
>

>           To: publicesvfoxpro@googlegroups.com

>                 To: publicesvfoxpro@googlegroups.com

[Programas ToP]

Una t�cnica que alguna vez he aplicado para ese caso del pedido en l�nea
o la venta del supermercado, cittas desde un call center y similares:

Se graba desde el primer item la factura: n�mero, cliente, etc.
Cada item se descuenta del stock y se acumula el valor a la factura de
forma individual.
Si no hay recaudo la factura puede quedar incompleta en cuanto a los
items comprados pero es consistente y terminada.
Eso es lo que ocurre en general en los almacenes de cadena y por eso
deben llamar al supervisor para poder anular un item porque de una vez
queda guardado y descargado el stock.

Si hay recaudo o cobro al final podr�a quedar abortada en alg�n item por
cualquier evento: caida del servidor, apag�n, bloqueo o lo que sea
faltar�a el recaudo y deber�a entrar en alg�n proceso de auditor�a.
Para citas m�dicas por ejemplo en call centers con muchos usuarios es la
�nica manera de no volverse loco. O al menos yo no he encontrado otra.
Espero que a alguien le sirva la idea.

Saludos cordiales

Manuel Tovar Ruiz
Barranquilla - COLOMBIA

Antes de imprimir este correo piensa en la contribuci�n que puedes hacer al medio ambiente.

Please consider your environmental responsibility and commitment before printing.

El 15/05/2012 06:53 p.m., Hugo C. escribi�:

> Interesante el debate.
>
> Saludos.
>
> On 15 mayo, 17:39, "Walter R. Ojeda Valiente"<w...@hotmail.com>
> wrote:
>> Hola Guillermo
>>

>> Eso depende del tipo de transacci�n y tambi�n acabo de publicar otra alternativa.

>>
>> Saludos.
>>
>> Walter.
>>
>> Date: Tue, 15 May 2012 16:34:27 -0700
>> From: gols...@gmail.com
>> To: publice...@googlegroups.com
>> Subject: Re: [vfp] Descontar Stock en linea o en lotes
>>
>> Walter, una duda, al comenzar el START TRANSACTION ya en la base de datos se descuenta el stock, y queda visible ese descuento desde otros equipos ?
>> Yo crei que se necesitaba el COMMIT para que quedara grabado y se reflejara en la B de Datos.
>>
>> Saludos
>> Guillermo
>>

>> El martes, 15 de mayo de 2012 20:09:57 UTC-3, Walter R. Ojeda Valiente escribi�:
>>
>> Yo estoy hablando de SQL (Firebird, especificamente) y supongo que H�ctor tambi�n pues �l dice que usa Postgre.
>>
>> Exactamente, con el primer �tem ya hay un START TRANSACTION que finaliza con un ROLLBACK si la venta no se realiz� por alg�n motivo (aumentando por lo tanto nuevamente la cantidad en stock de cada producto) o con un COMMIT (en cuyo caso, la cantidad descontada simplemente se confirma y queda descontada).
>>
>> El algoritmo ser�a el siguiente:

>>
>> START TRANSACTION
>> - Descontar del stock
>> - Descontar del stock
>> - Descontar del stock
>> Si COMMIT

>> Nada, est� todo OK
>> Fin si
>> Si ROLLBACK
>> - Aumentar el stock de cada producto (lo cual se realiza autom�ticamente)
>> Fin si
>>
>> Al llegar a esta l�nea siempre tienes tu stock correcto.

>>
>> Debo aclarar que las transacciones en Firebird tienen 4 niveles de aislamiento, la que se debe usar para lo anteriormente expuesto es la READ UNCOMMITED.
>>
>> Saludos.
>>
>> Walter.
>>
>> Date: Tue, 15 May 2012 17:54:41 -0500
>> From: programas...@gmail.com
>> To: publice...@googlegroups.com
>> Subject: Re: [vfp] Descontar Stock en linea o en lotes
>>
>> Osea que desde el primer item arranca un START TRANSACTION? y cuando
>> termina la factura hace un COMMIT?
>>
>> Estamos hablando de un escenario con un motor de BD o con tablas
>> nativas?
>>
>> Saludos cordiales
>>
>> Manuel Tovar Ruiz
>> Barranquilla - COLOMBIA
>>

>> Antes de imprimir este correo piensa en la contribuci�n que puedes hacer al medio ambiente.

>> Please consider your environmental responsibility and commitment before printing.
>>

>> El 15/05/2012 05:53 p.m., Walter R. Ojeda Valiente escribi�:
>>
>> Los �tems se descuentan pero no se confirman hasta que se hace
>> el COMMIT correspondiente.
>>
>> O sea que si la transacci�n termina con un ROLLBACK o porque
>> cay� el Servidor entonces esos �tems retornan al stock y todos

>> contentos.
>>
>> Saludos.
>>
>> Walter.
>>
>> Date: Tue, 15 May 2012 17:48:28 -0500
>>
>> From: programas...@gmail.com
>>
>> To: publice...@googlegroups.com
>>
>> Subject: Re: [vfp] Descontar Stock en linea o en lotes
>>

>> C�mo manejan que la factura no se complete por alguna raz�n y
>> los items ya est�n descargados los items del stock?
>>
>> Que no se descuente por ejemplo porque se apag� la terminal,
>> se bloque�, cay� el servidor, etc.

>>
>> Saludos cordiales
>>
>> Manuel Tovar Ruiz
>> Barranquilla - COLOMBIA
>>

>> Antes de imprimir este correo piensa en la contribuci�n que puedes hacer al medio ambiente.

>> Please consider your environmental responsibility and commitment before printing.
>>

>> El 15/05/2012 05:44 p.m., Walter R. Ojeda Valiente escribi�:

>>
>> Para todos los efectos desde el punto de

>> vista de los otros clientes ya ha salido. Solamente a�n no
>> se ha finalizado la transacci�n comercial, que es otra

>> cosa. No confundas.
>>
>> Tu forma de trabajar puede ser aceptable si tienes una,

>> dos o tres computadoras y cada cajero est� cerca de los
>> dem�s cajeros y puede preguntarle: �est�s vendiendo

>> frascos de dulce de naranja?. Pero en una empresa grande,

>> donde hay 20, 30, 40 � m�s cajeros tal cosa es imposible.
>> Adem�s, no te olvides que los pedidos tambi�n pueden
>> hacerse por tel�fono, por fax, por e-mail, por celular o
>> por p�gina web.
>>
>> �Qu� pasa si se reciben dos pedidos por tel�fono, cada uno
>> de ellos con un mont�n de �tems y no hay suficiente
>> cantidad en stock para satisfacer ambos pedidos? Seg�n tu
>> m�todo, reci�n en el momento de hacer click sobre el bot�n
>> "Grabar" el segundo usuario sabr� que no puede vender un
>> �tem, que est� segundo o tercero en una lista de 15.

>> Entonces tiene que llamarle al cliente y decirle: "lo

>> siento mucho, el producto XXX no te lo podr� vender porque
>> ahora reci�n mi programa me avisa que no tengo tanta

>> cantidad en stock. Cuando me estabas dictando lo que

>> necesitabas me dijo que ten�a suficiente cantidad pero

>> ahora me dice que no".
>>

>> Hmmmmmmmmmm, a m� particularmente no me gusta esa
>> situaci�n, ya que ni el usuario ni el cliente del usuario
>> quedar�n muy conformes. No s� que ventajas tienes al
>> descontar del stock solamente despu�s del COMMIT, espero

>> que me digas alguna.
>>
>> Y como ya dije anteriormente, actualizar una columna para
>> saber la cantidad actual en stock de un producto no es

>> recomendable en SQL, s� es aceptable en .DBF

>> escribi�:
>>
>> Es que est�s hablando de dos cosas

>> distintas:
>>
>> - Por un lado, el stock de cada producto que se
>> ve en las pantallas de cada computadora mientras

>> se est�n realizando las ventas

>>
>> - Por el otro lado, el historial de los
>> movimientos
>>

>> En el primer caso, la transacci�n puede

>> confirmarse (con un COMMIT) o no (con un
>> ROLLBACK)
>>
>> En el segundo caso, solamente se muestran las
>> transacciones confirmadas (con COMMIT)
>>
>> Y con respecto al ejemplo del supermercado, un

>> cliente puede llamar por tel�fono y decir:

>> "quiero 12 frascos de dulce de naranja", el
>> usuario mira en su computadora, ve que hay 12
>> frascos, le factura, y luego se da cuenta que tu

>> programa le minti� porque solamente hab�a 11.
>>
>> Y algo as� podr�a suceder no solamente en un
>> supermercado sino en much�simos otros negocios,

>> como farmacias, ventas de repuestos para

>> veh�culos, ventas de electrodom�sticos, ventas

>> de ropas, etc.
>>
>> Para evitarte problemas, lo mejor es que cuando

>> en una computadora se registr� una venta se haga

>> el descuento del stock, si luego la venta no se
>> ...
>>

>> leer m�s �

[Walter R. Ojeda Valiente]

Gracias.

Desde mi punto de vista, sería muy molesto para el usuario (o usuaria, claro) estar escribiendo una venta de digamos 20 productos distintos para que en el momento de grabar el programa le diga:
- No hay suficiente cantidad en stock del producto 1
- No hay suficiente cantidad en stock del producto 2
- No hay suficiente cantidad en stock del producto 3
- ...
- No hay suficiente cantidad en stock del producto 20

Y además de la pérdida de tiempo en que incurrió tener que llamarle por teléfono al cliente y decirle: "Lo siento señor cliente, no podré venderle todo lo que me pidió porque mientras usted me dictaba lo que necesitaba este programa me decía que tenía suficiente cantidad en stock y ahora me dice que no. Será otro día, si usted tiene más suerte....¡¡¡Y por favor deje de insultarme, que no es mi culpa!!!".

Saludos.

Walter.

> Date: Tue, 15 May 2012 16:53:18 -0700
> Subject: [vfp] Re: Descontar Stock en linea o en lotes
> From: hcch...@gmail.com
> To: publice...@googlegroups.com

[Walter R. Ojeda Valiente]

No confundas, nada se graba hasta llegar al COMMIT.

Lo que se está haciendo es informarle a las demás computadoras que el stock de un producto ha disminuído, para que no intenten vender lo que no existe.

Luego, si no se confirma la venta, se vuelve a aumentar la cantidad en stock de ese producto.

Es simplemente eso.

Saludos.

Walter.

---

Date: Tue, 15 May 2012 17:01:16 -0700
From: gol...@gmail.com
To: publice...@googlegroups.com
Subject: [vfp] Re: Descontar Stock en linea o en lotes

[Hernan]

y esa operación  porque no se lo dejan a un trigger?

 

[Walter R. Ojeda Valiente]

En general, estoy de acuerdo contigo.

Tengo un cliente que distribuye medicamentos al por mayor, sus clientes son las farmacias, no le vende a personas físicas, solamente le vende a las farmacias. Desde las farmacias llaman por teléfono para hacer los pedidos y hay de 6 a 8 operadores con sus respectivas computadoras, auriculares y micrófonos para registrar los pedidos.

Cada operador escucha en su auricular el pedido que le hace una farmacia, lo va registrando en la computadora y al hacer click sobre el botón "Grabar" se imprime la Factura (en alguna de las impresoras que están en otra habitación, para que no les moleste el ruido que hacen al imprimir).

Hay unos jovencitos cuya tarea es llevar esas Facturas al depósito, guardar en una bolsa el pedido y llevarlo en una motocicleta a la Farmacia.

Si los operadores supieran que no hay suficiente cantidad en stock de un medicamento solamente en el momento de hacer click sobre el botón "Grabar" entonces eso sería muy molesto para ellos. Es mucho mejor que en el momento que el cliente le está dictando el pedido ya le digan que no hay tanta cantidad.

Saludos.

Walter.

> Date: Tue, 15 May 2012 19:03:17 -0500
> From: progra...@gmail.com
> To: publice...@googlegroups.com
> Subject: Re: [vfp] Re: Descontar Stock en linea o en lotes
>
> Una técnica que alguna vez he aplicado para ese caso del pedido en línea

> o la venta del supermercado, cittas desde un call center y similares:
>

> Se graba desde el primer item la factura: número, cliente, etc.

> Cada item se descuenta del stock y se acumula el valor a la factura de
> forma individual.
> Si no hay recaudo la factura puede quedar incompleta en cuanto a los
> items comprados pero es consistente y terminada.
> Eso es lo que ocurre en general en los almacenes de cadena y por eso
> deben llamar al supervisor para poder anular un item porque de una vez
> queda guardado y descargado el stock.
>

> Si hay recaudo o cobro al final podría quedar abortada en algún item por
> cualquier evento: caida del servidor, apagón, bloqueo o lo que sea
> faltaría el recaudo y debería entrar en algún proceso de auditoría.
> Para citas médicas por ejemplo en call centers con muchos usuarios es la
> única manera de no volverse loco. O al menos yo no he encontrado otra.

> Espero que a alguien le sirva la idea.
>
> Saludos cordiales
>
> Manuel Tovar Ruiz
> Barranquilla - COLOMBIA
>

> Antes de imprimir este correo piensa en la contribución que puedes hacer al medio ambiente.

> Please consider your environmental responsibility and commitment before printing.
>
>
> El 15/05/2012 06:53 p.m., Hugo C. escribió:
> > Interesante el debate.
> >
> > Saludos.
> >
> > On 15 mayo, 17:39, "Walter R. Ojeda Valiente"<w...@hotmail.com>
> > wrote:
> >> Hola Guillermo
> >>

> >> Eso depende del tipo de transacción y también acabo de publicar otra alternativa.

> >>
> >> Saludos.
> >>
> >> Walter.
> >>
> >> Date: Tue, 15 May 2012 16:34:27 -0700
> >> From: gols...@gmail.com
> >> To: publice...@googlegroups.com
> >> Subject: Re: [vfp] Descontar Stock en linea o en lotes
> >>
> >> Walter, una duda, al comenzar el START TRANSACTION ya en la base de datos se descuenta el stock, y queda visible ese descuento desde otros equipos ?
> >> Yo crei que se necesitaba el COMMIT para que quedara grabado y se reflejara en la B de Datos.
> >>
> >> Saludos
> >> Guillermo
> >>

> >> El martes, 15 de mayo de 2012 20:09:57 UTC-3, Walter R. Ojeda Valiente escribió:
> >>
> >> Yo estoy hablando de SQL (Firebird, especificamente) y supongo que Héctor también pues él dice que usa Postgre.
> >>
> >> Exactamente, con el primer ítem ya hay un START TRANSACTION que finaliza con un ROLLBACK si la venta no se realizó por algún motivo (aumentando por lo tanto nuevamente la cantidad en stock de cada producto) o con un COMMIT (en cuyo caso, la cantidad descontada simplemente se confirma y queda descontada).
> >>
> >> El algoritmo sería el siguiente:

> >>
> >> START TRANSACTION
> >> - Descontar del stock
> >> - Descontar del stock
> >> - Descontar del stock
> >> Si COMMIT

> >> Nada, está todo OK
> >> Fin si
> >> Si ROLLBACK
> >> - Aumentar el stock de cada producto (lo cual se realiza automáticamente)
> >> Fin si
> >>
> >> Al llegar a esta línea siempre tienes tu stock correcto.

> >>
> >> Debo aclarar que las transacciones en Firebird tienen 4 niveles de aislamiento, la que se debe usar para lo anteriormente expuesto es la READ UNCOMMITED.
> >>
> >> Saludos.
> >>
> >> Walter.
> >>
> >> Date: Tue, 15 May 2012 17:54:41 -0500
> >> From: programas...@gmail.com
> >> To: publice...@googlegroups.com
> >> Subject: Re: [vfp] Descontar Stock en linea o en lotes
> >>
> >> Osea que desde el primer item arranca un START TRANSACTION? y cuando
> >> termina la factura hace un COMMIT?
> >>
> >> Estamos hablando de un escenario con un motor de BD o con tablas
> >> nativas?
> >>
> >> Saludos cordiales
> >>
> >> Manuel Tovar Ruiz
> >> Barranquilla - COLOMBIA
> >>

> >> Antes de imprimir este correo piensa en la contribución que puedes hacer al medio ambiente.

> >> Please consider your environmental responsibility and commitment before printing.
> >>

> >> El 15/05/2012 05:53 p.m., Walter R. Ojeda Valiente escribió:
> >>
> >> Los ítems se descuentan pero no se confirman hasta que se hace
> >> el COMMIT correspondiente.
> >>
> >> O sea que si la transacción termina con un ROLLBACK o porque
> >> cayó el Servidor entonces esos ítems retornan al stock y todos

> >> contentos.
> >>
> >> Saludos.
> >>
> >> Walter.
> >>
> >> Date: Tue, 15 May 2012 17:48:28 -0500
> >>
> >> From: programas...@gmail.com
> >>
> >> To: publice...@googlegroups.com
> >>
> >> Subject: Re: [vfp] Descontar Stock en linea o en lotes
> >>

> >> Cómo manejan que la factura no se complete por alguna razón y

> >> los items ya están descargados los items del stock?

> >>
> >> Que no se descuente por ejemplo porque se apagó la terminal,

> >> se bloqueó, cayó el servidor, etc.

> >>
> >> Saludos cordiales
> >>
> >> Manuel Tovar Ruiz
> >> Barranquilla - COLOMBIA
> >>

> >> Antes de imprimir este correo piensa en la contribución que puedes hacer al medio ambiente.

> >> Please consider your environmental responsibility and commitment before printing.
> >>
> >> El 15/05/2012 05:44 p.m., Walter R. Ojeda Valiente escribió:
> >>
> >> Para todos los efectos desde el punto de

> >> vista de los otros clientes ya ha salido. Solamente aún no
> >> se ha finalizado la transacción comercial, que es otra

> >> cosa. No confundas.
> >>
> >> Tu forma de trabajar puede ser aceptable si tienes una,

> >> dos o tres computadoras y cada cajero está cerca de los

> >> demás cajeros y puede preguntarle: ¿estás vendiendo

> >> frascos de dulce de naranja?. Pero en una empresa grande,

> >> donde hay 20, 30, 40 ó más cajeros tal cosa es imposible.

> >> Además, no te olvides que los pedidos también pueden

> >> hacerse por teléfono, por fax, por e-mail, por celular o
> >> por página web.
> >>
> >> ¿Qué pasa si se reciben dos pedidos por teléfono, cada uno
> >> de ellos con un montón de ítems y no hay suficiente
> >> cantidad en stock para satisfacer ambos pedidos? Según tu

> >> método, recién en el momento de hacer click sobre el botón

> >> "Grabar" el segundo usuario sabrá que no puede vender un
> >> ítem, que está segundo o tercero en una lista de 15.

> >> Entonces tiene que llamarle al cliente y decirle: "lo

> >> siento mucho, el producto XXX no te lo podré vender porque

> >> ahora recién mi programa me avisa que no tengo tanta

> >> cantidad en stock. Cuando me estabas dictando lo que

> >> necesitabas me dijo que tenía suficiente cantidad pero

> >> ahora me dice que no".
> >>

> >> Hmmmmmmmmmm, a mí particularmente no me gusta esa
> >> situación, ya que ni el usuario ni el cliente del usuario
> >> quedarán muy conformes. No sé que ventajas tienes al
> >> descontar del stock solamente después del COMMIT, espero

> >> que me digas alguna.
> >>
> >> Y como ya dije anteriormente, actualizar una columna para
> >> saber la cantidad actual en stock de un producto no es

> >> recomendable en SQL, sí es aceptable en .DBF

> >> escribió:
> >>
> >> Es que estás hablando de dos cosas

> >> distintas:
> >>
> >> - Por un lado, el stock de cada producto que se
> >> ve en las pantallas de cada computadora mientras

> >> se están realizando las ventas

> >>
> >> - Por el otro lado, el historial de los
> >> movimientos
> >>

> >> En el primer caso, la transacción puede

> >> confirmarse (con un COMMIT) o no (con un
> >> ROLLBACK)
> >>
> >> En el segundo caso, solamente se muestran las
> >> transacciones confirmadas (con COMMIT)
> >>
> >> Y con respecto al ejemplo del supermercado, un

> >> cliente puede llamar por teléfono y decir:

> >> "quiero 12 frascos de dulce de naranja", el
> >> usuario mira en su computadora, ve que hay 12
> >> frascos, le factura, y luego se da cuenta que tu

> >> programa le mintió porque solamente había 11.
> >>

> >> Y algo así podría suceder no solamente en un
> >> supermercado sino en muchísimos otros negocios,

> >> como farmacias, ventas de repuestos para

> >> vehículos, ventas de electrodomésticos, ventas

> >> de ropas, etc.
> >>
> >> Para evitarte problemas, lo mejor es que cuando

> >> en una computadora se registró una venta se haga

> >> el descuento del stock, si luego la venta no se
> >> ...
> >>

> >> leer más »

[Walter R. Ojeda Valiente]

¿Cuál es tu idea, puedes explicarte mejor?

No la entendí.

Saludos.

Walter.

---

Date: Tue, 15 May 2012 19:24:01 -0500
Subject: Re: [vfp] Re: Descontar Stock en linea o en lotes
From: hern...@gmail.com
To: publice...@googlegroups.com

[GeoSys Diseño de Software]

Bueno, esto si que es un dilema, porque que tal en un Súper Mercado donde los clientes cogen el producto, pero un cliente está llamando y haciendo el pedido por teléfono.

El que toma el pedido va ingresando los productos conforme el cliente le dicta, en ese momento hay 12 frascos de dulce de naranja por lo que el sistema acepta el pedido para el cliente del teléfono, pero resulta que al momento después llega un cliente a la góndola y físicamente en la góndola hay 12 frascos de dulce de naranja y inmediatamente toma 6 para el carrito.

Cuando el que estaba tomando el pedido por teléfono llega a la góndola ya va a encontrar solo 6 frascos, porque ya el cliente que andaba en el súper ya se llevó 6 frascos.

jajajajaja, esto si que está conversado.

Saludos

Anthony Contreras Peralta

Costa Rica.

[Walter R. Ojeda Valiente]

Pues sí, tienes razón, es algo que podría ocurrir con la tecnología actual (quizás dentro de unos años unos robots se vayan encargando de los pedidos y algo así sea imposible de ocurrir), pero de todas maneras nosotros como profesionales de la Informática tenemos que tratar de prever y de solucionar todo lo que esté a nuestro alcance. Seguro que no podremos hacerlo en el 100% de todos los casos posibles pero en los que sí podemos deberíamos hacerlo.

Saludos.

Walter.

---

Date: Tue, 15 May 2012 18:33:03 -0600
Subject: Re: [vfp] Re: Descontar Stock en linea o en lotes
From: geos...@gmail.com
To: publice...@googlegroups.com

[Guillermo MDQ]

La verdad, que si el supermercado tiene solamente 12 frascos de dulce de naranja es bastante pobreton, jajaja.

Saludos
Guillermo

El martes, 15 de mayo de 2012 22:32:43 UTC-3, Walter R. Ojeda Valiente escribió:

Pues sí, tienes razón, es algo que podría ocurrir con la tecnología actual (quizás dentro de unos años unos robots se vayan encargando de los pedidos y algo así sea imposible de ocurrir), pero de todas maneras nosotros como profesionales de la Informática tenemos que tratar de prever y de solucionar todo lo que esté a nuestro alcance. Seguro que no podremos hacerlo en el 100% de todos los casos posibles pero en los que sí podemos deberíamos hacerlo.

Saludos.

Walter.

---

Date: Tue, 15 May 2012 18:33:03 -0600
Subject: Re: [vfp] Re: Descontar Stock en linea o en lotes
From: geos...@gmail.com

To: publicesvfoxpro@googlegroups.com

To: publicesvfoxpro@googlegroups.com

[ZeRoberto]

@GeoSys

 

Justamente a eso es lo que queria llegar comprometer lo que supuestamente el cliente va a comprar, para evitar que otro vendedor nos deje sin stock.

 

Si el cliente decide no comprar simplemente se anula ese pedido, y todos los saldos vuelven a la normalidad, pero el problema esta si ocurre algun apagon, los datos quedan reflejados, bueno aunque con uso de Motores de BD se tiene la opcion de hacer un Rollback para deshacer el pedido.

 

Ahora si descargamos el stock al momento de confirmar la factura, tambien podemos deshacerlo con un Rollback pero cada rato le vamos a estar diciendo al cliente, lo siento el cafe que ud pidio se acabo. Y hasta que pida otra cosa, lo demas productos ya se habran acabado.

 

Saludos

[Carlos Alfaro]

Pero, en este caso lo que se hace, es que se separa la venta in situ, así cuando se toma de bodega para la góndola se rebaja, asi saben de cuanto disponen para la venta via teléfono, web, etc.

 

Saludos,

 

Carlos Alfaro

[Pablo Daniel Lissa]

Hola gente:

Muy interesante el debate que se armó. Yo, por mi parte entiendo el
enfoque de Walter y comparto su opinión sobre las ventajas y la
potencia de las transacciones. Sin embargo, algo que no me gusta es
que una transacción tenga un alto tiempo de persistencia en el
sistema. Me parece ideal cuando se utiliza para ejecutar el conjunto
de comandos lo más secuencialmente posible, con el mínimo tiempo de
espera entre los comandos. Según mi punto de vista, esto rompe un poco
con la atomicidad que debe tener una transaccion. Se suele hablar de
la ACIDez de una transacción para indicar las características
deseables (ACID: Atomicity, Consistency, Isolation, Durability -
Atomicidad, Consistencia, Aislamiento, Durabilidad).

Otro tema es que hay que tener cuidado de mantener conexiones
distintas para la transacción activa (la cual implica, aunque sea
temporalmente, un modelo conectado) y el resto de las operaciones,
puesto que de lo contrario, todos los comandos sobre la Base de Datos
quedarían "enganchados" al manejo transaccional que, si no termina en
COMMIT puede ser perjudicial.

En resumen, entiendo el enfoque de Walter, pero me parece más potable
apuntar al enfoque que expresó Héctor para este escenario. Y si el
cliente no se apuró a comprar el último frasco de dulce de naranja, lo
lamento, que se entere al momento de querer confirmar la compra.

Por último, cuando el modelo de funcionamiento es así (ventas físicas
y/o virtuales, por llamarlas de alguna manera), me parece que lo mejor
es no exponer todo el stock disponible para ventas virtuales.

Saludos.
------------------------------------------------------------------------------------------------------------------------------

On 15 mayo, 23:15, ZeRoberto <zeroha...@gmail.com> wrote:
> @GeoSys
>
> Justamente a eso es lo que queria llegar comprometer lo que supuestamente
> el cliente va a comprar, para evitar que otro vendedor nos deje sin stock.
>
> Si el cliente decide no comprar simplemente se anula ese pedido, y todos
> los saldos vuelven a la normalidad, pero el problema esta si ocurre algun
> apagon, los datos quedan reflejados, bueno aunque con uso de Motores de BD
> se tiene la opcion de hacer un Rollback para deshacer el pedido.
>
> Ahora si descargamos el stock al momento de confirmar la factura, tambien
> podemos deshacerlo con un Rollback pero cada rato le vamos a estar diciendo
> al cliente, lo siento el cafe que ud pidio se acabo. Y hasta que pida otra
> cosa, lo demas productos ya se habran acabado.
>
> Saludos
>
> El 15 de mayo de 2012 19:33, GeoSys Diseño de Software

> <geosy...@gmail.com>escribió:

>
>
>
>
>
>
>
> > Bueno, esto si que es un dilema, porque que tal en un Súper Mercado donde
> > los clientes cogen el producto, pero un cliente está llamando y haciendo el
> > pedido por teléfono.
>
> > El que toma el pedido va ingresando los productos conforme el cliente le
> > dicta, en ese momento hay 12 frascos de dulce de naranja por lo que el
> > sistema acepta el pedido para el cliente del teléfono, pero resulta que al
> > momento después llega un cliente a la góndola y físicamente en la góndola
> > hay 12 frascos de dulce de naranja y inmediatamente toma 6 para el carrito.
>
> > Cuando el que estaba tomando el pedido por teléfono llega a la góndola ya
> > va a encontrar solo 6 frascos, porque ya el cliente que andaba en el súper
> > ya se llevó 6 frascos.
>
> > jajajajaja, esto si que está conversado.
>

> > *Saludos*
> > *
> > *
> > *Anthony Contreras Peralta*
> > *
> > *
> > *Costa Rica.*

[Arnaldo Toledano]

En el caso hipotético que planteas de venta en góndola y venta telefónica, existen métodos.
El pedido telefónico es TOMADO pero no confirmado.
Incluso cuando lo realizas te dan opciones para productos alternativos.
Por lo tanto un empleado va con la lista de pedido  a la góndola, lo completa y recién allí se produce la facturación.
Es decir QUE ES IMPROBABLE que el stock quede "en negativo".


Arnaldo

--
Arnaldo Toledano Tesys Informática Córdoba Argentina

[Daniel Sánchez]

Metiéndome en el tema yo lo veo que existe dos tipos de negocio de ventas, el primero seria el de mostrador esto quiere decir que el cliente no toma de góndola u estante el producto si no que hay un despachador o tomador del pedido y este se encarga de ver las existencias en su sistema y despachando lo que tiene stock y descargando el stock conforme va facturando cierra el documento ya el stock quedo descargado así no lo recoga estaría como no disponible a no ser que anule la factura quedaría la mercadería nuevamente disponible, ahora el caso dos tipo supermercado ahí no es necesario saber o estar actualizando o consultando el stock ya que la persona llegara con el producto encontrado y nunca pues llevara mas de lo que este disponible, ahora si el súper tiene un sistema de adicionalmente de ventas corporativas o a empresas por teléfono pues lo solucionaría manejando 2 almacenes 1 el almacén de publico general y el almacén principal donde manejaría mi stock para ventas corporativas y si por alguna razón necesito mas quedaría en confirmar el saldo que este en góndola es decir en el almacén de ventas publico general ya que este se tiene que verificar en su góndola la cantidad actual ya que puede estar en tránsito por parte del cliente (es decir en su carrito de compras). En el caso de supermercados estos realizan un cierre al final del día donde cuadran sus stock y realizan sus reposiciones de los productos necesarios trasladando del almacén principal al general de venta para su posterior venta al publico. 

Es mi apreciación en cuanto a dicho tema.

Saludos

--
Enviado desde dispositivo móvil

[mpulla]

Buen punto Pablo

<<Algo que no me gusta es que una transacción tenga un alto tiempo de persistencia en el sistema.

Trabajo con Sql Server y lo mas recomendable es que una transaccion dure el menor tiempo posible, por que ademas de consumir recursos, te genera bloqueos

El cliente A compra los productos Producto 1, Producto 2, Producto 3 y se mantiene en la linea o en caja por cualquier razon mas de 5', mientra el cliente B esta intentando comprar el producto Producto 3 tendria que esperar a que culmine la transaccion del cliente A

Claro que el impacto de este problema dependera del diseño de la db.

Saludos.
Mauricio

[Walter R. Ojeda Valiente]

¿Por qué tendría que esperar?

Al menos en Firebird no.

Las transacciones pueden ser WAIT o NOWAIT. En el primer caso (WAIT) la segunda transacción debe esperar que finalice la primera. En el segundo caso (NOWAIT) no hay espera.

De todas maneras, en el caso que estamos considerando no hay actualización de la tabla de productos porque en ella no existe una columna llamada CANTIDAD_ACTUAL o similar (bueno, al menos yo no la utilizo).

Saludos.

Walter.

---

Date: Wed, 16 May 2012 07:46:12 -0700
From: jmaur...@yahoo.es

To: publice...@googlegroups.com
Subject: [vfp] Re: Descontar Stock en linea o en lotes

[Pablo Daniel Lissa]

Eso depende de la forma de diseñar. Como dijo Mauricio, un bloqueo
empeoraría las cosas.

Incluso, sin bloqueo, nada evitaría la posibilidad de que queden
peticiones sin atender por resultado de una transacción activa que
puede ser vuelta atrás. Ejemplo: 10 clientes se quedan sin su frasco
de dulce porque el que tomó el último de la góndola, luego, fue en
busca de 25 productos más, para que, al final, como no le daba el
dinero, decida no llevar el frasco de dulce. A eso me refería con la
atomicidad de la transacción y la larga duración de la persistencia de
dicha transacción en el sistema.

Resultó práctico el ejemplo.

Saludos.
----------------------------------------------------------------------------------------------------------------------------

On 16 mayo, 11:51, "Walter R. Ojeda Valiente" <w...@hotmail.com>
wrote:

> ¿Por qué tendría que esperar?
>
> Al menos en Firebird no.
>
> Las transacciones pueden ser WAIT o NOWAIT. En el primer caso (WAIT) la segunda transacción debe esperar que finalice la primera. En el segundo caso (NOWAIT) no hay espera.
>
> De todas maneras, en el caso que estamos considerando no hay actualización de la tabla de productos porque en ella no existe una columna llamada CANTIDAD_ACTUAL o similar (bueno, al menos yo no la utilizo).
>
> Saludos.
>
> Walter.
>

> Date: Wed, 16 May 2012 07:46:12 -0700

> From: jmaurici...@yahoo.es

[mpulla]

Hola Walter.

Muy interesante Firebird con su transaccion WAIT Y NOWAIT, suena con insertar tablas en buffers que los demas usuarios pueden ver.

Por mi parte tampo utilizo CANTIDAD_ACTUAL, utilizo una vista indexada que mantiene la CANTIDAD_ACTUAL dependiendo de los movimentos de la tabla, según la docuementacion de Sql Server mas optimo que estar haciendo:

Select icodigo, sum(nCantidad)
From Movimientos
 where icodigo = 123
 Group by icodigo

Por lo que comentas para saber la cantidad actual haces un select, entonces Firebird debe ser muy potente al trabajar de esta manera y tener un buen rendimiento en un ambiente exigente.

Saludos.
Mauricio

[Walter R. Ojeda Valiente]

Pero la alternativa es que recién en el momento de grabar el usuario se entere que no hay suficiente cantidad en stock, con los anodinos mensajes de error correspondientes.

Su sistema le estaría engañando, porque en el momento de cargar los ítems le dijo que había existencia y unos minutos después al intentar grabarlos le dice que ahora ya no hay.

Saludos.

Walter.

> Date: Wed, 16 May 2012 09:20:18 -0700

> Subject: [vfp] Re: Descontar Stock en linea o en lotes

> From: pablo.dan...@gmail.com
> To: publice...@googlegroups.com

[Walter R. Ojeda Valiente]

Hola Mauricio

Hasta ahora siempre me ha funcionado muy bien, pero lo de la vista indexada me parece interesante, tendré que hacer algunas pruebas para comparar los rendimientos.

Saludos.

Walter.

---

Date: Wed, 16 May 2012 09:22:42 -0700
From: jmaur...@yahoo.es
To: publice...@googlegroups.com
Subject: Re: [vfp] Re: Descontar Stock en linea o en lotes

[Pablo Daniel Lissa]

Ni hablar... Estaremos de acuerdo en que la solución ideal a este
problema no se va a poder determinar. Se va a necesitar conocer los
pormenores del circuito para saber qué se puede ceder (la consistencia
total del procedimiento o la simultaneidad de atender varios procesos
con cierta incertidumbre). Y con todo esto ya nos vamos a una toma de
decisiones propia del análisis de requerimientos.

Yo ya lo expresé... En mi opinión, me gustan las transacciones (que se
concreten en corto tiempo), pero, en este caso, buscaría llegar a algo
parecido a lo que propuso Héctor al principio.

Saludos.
------------------------------------------------------------------------------------------------------------

[Guillermo MDQ]

Walter, el Select que utilizas para calcular la Cantidad_Actual lo tienes dentro de un Procedimiento Almacenado ?
Porque se supone que tendria que tener mejor rendimiento que una vista.

Saludos
Guillermo

[Hector R. De los Santos]

@Pablo,

Estoy deacuerdo con tu punto, y es como comente anteriormente, me parece un esfuerzo innecesario hacerlo de la manera que plantea Walter.
Otra cosa con la cual estoy muy deacuerdo es sobre la ACIDez, esta demas decir que Firebird (y ni hablar PostgreSQL) respeta bastante este aspecto, hay que recordar que mientras una transaccion esta activa, los registros y/o tablas relacionadas se mantienen bloqueadas.

@Walter
Lo que Pablo dice sobre de tener la transaccion abierta en espera, es que mientras se van agregando productos a la factura se tiene una transaccion abierta (eso es lo que entiendo de tu modo de trabajar eso), si la factura se tarda media hora, 15min o lo que sea, (ya sea porque a un producto de los que iba a comprar no tenia codigo y lo fueron a buscar, que la tarjeta no pasa, o cualquier otra cosa)  ese mismo tiempo tendria la transaccion abierta, lo cual no es recomendable por lo que el mismo plantea, bloqueos de registros y tablas asi como rendimiento del motor

Tu modo plantea que hara un rollback si el cliente decide no comprar un producto luego de que es agregado , pero hay que tomar en cuenta que el cliente decide no comprar un articulo inmediatamente luego de que el cajero lo agrega, pasan varios articulos despues (que son rebajados de almacen)  y luego el dice "este no me lo llevo", y ahi es donde "se hace rollback ??" de una transaccion que "supuestamente" esta en esta en espera.


Pero este asunto es como ya habia comentado, son dos modos de trabajar los cuales tienen sus pros y sus contras, todo va a depender de los esceranarios.

:: HDS Consultores TI
Servidores | Redes | Programacion | GNU/Linux | PostgreSQL
Web: http://hdsconsultores.net
Blog: http://codigohds.com
Linux User #:320363

[Walter R. Ojeda Valiente]

No, una transacción no bloquea los registros en Firebird ya que "los lectores no bloquean a los escritores ni los escritores bloquean a los lectores".

Lo que hace es ir grabando un delta (un nuevo registro, pero que tiene solamente los cambios realizados)

Y además, yo no uso una columna CANTIDAD_ACTUAL o similar, lo que grabo (y puedo deshacer con el ROLLBACK) son los movimientos. Es muy distinto.

Saludos.

Walter.

---

Date: Wed, 16 May 2012 14:53:48 -0400
Subject: Re: [vfp] Re: Descontar Stock en linea o en lotes
From: zah...@gmail.com
To: publice...@googlegroups.com

[jonathan Francisco]

Buenas Noches.

si descuentas al momento de que el cliente pasa el producto como maneja si el server o el equipo de apaga, por que ya le dijiste que el producto x = cantidad actual menos cantidad que el cliente esta intentando facturar.

En mi opinión pondría a trabajar el motor de DB más de la cuenta.

Una sugerencia sería rebajar cuando salvo la factura. creo el movimiento del producto etc.

en el caso de que los cliente realicen pedido por internet,por telefono, email. etc. son pedidos.

En mi caso tengo un  proceso que se llama pedido se almacena en una tablas de pedidos.

recuerda que aunque el cliente pide debe ser autorizado por alguien. x usuario .

los pedidos los convierto a facturación con un botton desde el pedido o desde la facturacion selecciono el cliente y busco los pedidos pendiente por facturar.

en la tabla de stock tengo columnas (existencia, cantidad reservada) que existencia-reservada me da la cantidad disponible. cuando facturo con la referencia del pedido descuento de la cantidad reservada y de la existencia.

si no se autoriza el pedido, es decir, si se cancela se devuelven las cantidades reservada.

sería una idea como dicen todos trabajamos de una manera distinta. y todo es desde el punto de vista que lo enfoques.

espero ayudar 

buenas noches.

Jonathan Francisco

GroupSoft Tecnology

República Dominicana

El martes, 15 de mayo de 2012 15:10:43 UTC-4, Roberto Reátegui Kanashiro escribió:

Con los DBF's yo descontaba el stock en linea osea agregaba un item
ponia la cantidad y automaticamente me descontaba el stock luego si
eliminaba el item restablecia el item.

Pero ahora estoy trabajando con MySQL y no se si hacerlo de la misma
forma o descontar al final en un proceso por lotes usando
transacciones.

Que me recomiendan?

Saludos

El martes, 15 de mayo de 2012 15:10:43 UTC-4, Roberto Reátegui Kanashiro escribió:

Con los DBF's yo descontaba el stock en linea osea agregaba un item
ponia la cantidad y automaticamente me descontaba el stock luego si
eliminaba el item restablecia el item.

Pero ahora estoy trabajando con MySQL y no se si hacerlo de la misma
forma o descontar al final en un proceso por lotes usando
transacciones.

Que me recomiendan?

Saludos

[Carlos Miguel FARIAS]

Creo que esa forma (crear un archivo de pedido) es la mas apropiada,
porque el item esta "para entregar", entonces, no lo tenes que dar en
realidad de baja. El pedido lo que hace es "encolarlo", y recien
cuando Almacen confirma el retiro del stock (confeccionando el remito)
el producto se da realmente de baja (del stock) y pasa a estar en
estado de "transito", porque realmente, hasta que no te retorna el
remito firmado, no podes decir que el cliente lo recibio y por lo
tanto confirmar la facturación (o si la factura ya está hecha,
confirmar el monto en cuenta corriente).
Si la facturación es en supermercado, no tenes problema, porque el
producto ya se "bajo" (en realidad lo "bajo el cliente") del stock y
se factura item a la vista.
Saludos: Miguel, La Pampa (RA)

El 17/05/12, jonathan Francisco <groups...@gmail.com> escribió:

> Buenas Noches.
> si descuentas al momento de que el cliente pasa el producto como maneja si
> el server o el equipo de apaga, por que ya le dijiste que el producto x =
> cantidad actual menos cantidad que el cliente esta intentando facturar.
> En mi opinión pondría a trabajar el motor de DB más de la cuenta.
>
> Una sugerencia sería rebajar cuando salvo la factura. creo el movimiento
> del producto etc.
> en el caso de que los cliente realicen pedido por internet,por telefono,

> email. etc. son *pedidos.*
> *
> *
> *En mi caso tengo un proceso que se llama pedido se almacena en una tablas
> de pedidos.*
> *recuerda que aunque el cliente pide debe ser autorizado por alguien. x
> usuario .*
> *
> *
> *los pedidos los convierto a facturación con un botton desde el pedido o

> desde la facturacion selecciono el cliente y busco los pedidos pendiente

> por facturar.*
> *
> *
> *en la tabla de stock tengo columnas (existencia, cantidad reservada) que

> existencia-reservada me da la cantidad disponible. cuando facturo con la
> referencia del pedido descuento de la cantidad reservada y de la existencia.

> *
> *si no se autoriza el pedido, es decir, si se cancela se devuelven las
> cantidades reservada.*
> *
> *
> *sería una idea como dicen todos trabajamos de una manera distinta. y todo
> es desde el punto de vista que lo enfoques.*
> *
> *
> *espero ayudar *
> *buenas noches.*
> *
> *
> *Jonathan Francisco*
> *GroupSoft Tecnology*
> *República Dominicana*

[Miguel Antúnez]

Hay diversas formas para manejar stocks, ya sea como venta directa, pre-venta, packing, etc.

al margen del tipo de movimiento comercial, quiero centrarme al mismo hecho de rebajar el stock, en mi caso lo hago vía trigger, es decir al momento de hacer el INSERT en la tabla de movimientos, hace el UPDATE respectivo al stock, para esto los movimientos que manejo son + en los ingresos y - en las salidas. y solo aceptar INSERT no UPDATE ni DELETE, ya que en mis reglas un movimiento de almacén solo puede ser corregido con otro movimiento.

Saludos.

--
Miguel Angel Antúnez Camones
mant...@gmail.com

[Walter R. Ojeda Valiente]

Bueno, es que yo no uso una columna CANTIDAD_ACTUAL así que nada debo actualizar.

Saludos.

Walter.

---

Date: Thu, 17 May 2012 09:33:45 -0500

Subject: Re: [vfp] Re: Descontar Stock en linea o en lotes

From: mant...@gmail.com
To: publice...@googlegroups.com

[Guillermo MDQ]

Mike, ya que dices que no utilizas Update ni Delete para descargar el stock, como manejas esta situacion:

Estoy realizando un remito de varios articulos, cargo 5 articulos por dar un ejemplo, y grabo el remito.
Despues modifico el mismo remito para agregar algun articulo mas o modificar las cantidades de alguno de los 5 articulos que habia ingresado primero, y grabo nuevamente.
Como haces las modificaciones al stock en un caso como este ?

Saludos
Guillermo

 

El jueves, 17 de mayo de 2012 11:50:54 UTC-3, Walter R. Ojeda Valiente escribió:

Bueno, es que yo no uso una columna CANTIDAD_ACTUAL así que nada debo actualizar.

Saludos.

Walter.

---

Date: Thu, 17 May 2012 09:33:45 -0500
Subject: Re: [vfp] Re: Descontar Stock en linea o en lotes
From: mant...@gmail.com

To: publicesvfoxpro@googlegroups.com

[Miguel Antúnez]

En ese caso, lo que haría es manejar un saldo físico y un saldo disponible, el disponible solo es para que los demás no dispongan de ese stock y es el que vale para el sistema, el físico es cuando realmente el producto salio del almacén, para el manejo del stock disponible ahí si podrías usar UPDATES DELETE, aunque en mi caso también los manejaría puro INSERT ya que me quedaría la evidencia e historial de las transacciones. 

Lo que dice Walter también es valido, aunque no me animo hacer el calculo cada vez que lo requiera ya que en algunos escenarios seria muy lento, imagínate que en el banco que cada vez que tengas que consultar tu saldo se calcule con los movimientos;  esta practica si lo uso cuando quiero calcular saldos a una fecha, en ese caso tomo el saldo actual, resto los ingresos y sumo las salidas y tengo el saldo a una fecha X.

Saludos.

[Daniel Sánchez]

Hola Walter, el método que utilizadas es excelente ya que nunca darás información errónea sobre el stock pero en una aplicación con muchos usuarios y varias consultas concurrentes no seria cargar mucho al servidor realizando select calculando los movimientos de dicho producto, si dicho producto tiene pocos movimientos pues no se notaria pero si hablamos de un producto con un historial de varios años y de mucha rotación pues me parece que el GBD andaría muy ocupado y podría menguar su performance.

[Walter R. Ojeda Valiente]

Es muy cierto Daniel, hace unos cuantos años esta forma de trabajar habría tenido ese gran "pero", mas los tiempos han cambiado y ahora tenemos computadoras rapidísimas y anchos de banda gigantescos entonces ya no es un concerniente.

Además, si alguna vez notara que algunos productos tienen muchísimos movimientos y las consultas se ralentizan siempre tendría la posibilidad de usar una tabla auxiliar con los datos de esos productos y actualizar dicha tabla solamente.

Saludos.

Walter.

---

Date: Fri, 18 May 2012 06:40:18 -0500
Subject: Re: [vfp] Descontar Stock en linea o en lotes
From: resets...@gmail.com
To: publice...@googlegroups.com

[Carlos Miguel FARIAS]

Pero se puede solucionar si se mantienen los movimientos de los últimos meses (digamos un año) y los anteriores solo con el stock (llamemos le inicial). De esa manera, reducís la cantidad de registros en la bd, si esa fuese la preocupación.

Saludos: Miguel, La Pampa (RA)

[Guillermo MDQ]

Se supone tambien que de tanto en tanto se debe hacer un inventario del stock de mercaderias, asi que el select de consulta se haria con los movimientos a partir de la fecha del inventario en adelante.

Saludos
Guillermo

El viernes, 18 de mayo de 2012 22:19:34 UTC-3, Miguel escribió:

Pero se puede solucionar si se mantienen los movimientos de los últimos meses (digamos un año) y los anteriores solo con el stock (llamemos le inicial). De esa manera, reducís la cantidad de registros en la bd, si esa fuese la preocupación.
Saludos: Miguel, La Pampa (RA)

El 18 de mayo de 2012 11:06, Walter R. Ojeda Valiente <wr...@hotmail.com> escribió:

Es muy cierto Daniel, hace unos cuantos años esta forma de trabajar habría tenido ese gran "pero", mas los tiempos han cambiado y ahora tenemos computadoras rapidísimas y anchos de banda gigantescos entonces ya no es un concerniente.

Además, si alguna vez notara que algunos productos tienen muchísimos movimientos y las consultas se ralentizan siempre tendría la posibilidad de usar una tabla auxiliar con los datos de esos productos y actualizar dicha tabla solamente.

Saludos.

Walter.

---

Date: Fri, 18 May 2012 06:40:18 -0500
Subject: Re: [vfp] Descontar Stock en linea o en lotes
From: resets...@gmail.com

To: publicesvfoxpro@googlegroups.com

[Carlos Miguel FARIAS]

Si Guillermo, eso que indicas es el conocido inventario de fin de años a los efectos contables, pero posiblemente, a los efectos de la gestión de clientes (un CRM?) deberían mantenerse la historia de movimientos de varios años.
Dicho relevamiento físico, implicara ajustar contra el cliente "dedos largos" o "donde diablos estaban", para que la contabilidad balancee.

Saludos: Miguel, La Pampa (RA)

[Marino]

Muy inteteresante esta discucion sobre Stock de un item. Pero
considero que el si un articulo x, tiene un promedio de ventas de 100
unidades por mes, el sistema debe informar, por ejmeplo, al encargado
de compras, cuando el producto x llego al limite o stock que debe
hacer un nuevo pedido de dicho articulo. Si vende un promedio de 100
unidades mensuales, significa que vende un promedio de 25 unidades
semanales, por lo cual si el limite del producto x es 25, cuando el
cliente llama, quien le atiende por telefono debe de tomar algunas
precauciones en ese momento. Pero como dice Walter, nunca se va a
realizar un sistema 100%, pero hay que tratar de acercarse lo mas
posible

On 19 mayo, 19:16, Carlos Miguel FARIAS <carlosmiguelfar...@gmail.com>
wrote:

> Si Guillermo, eso que indicas es el conocido inventario de fin de años a
> los efectos contables, pero posiblemente, a los efectos de la gestión de
> clientes (un CRM?) deberían mantenerse la historia de movimientos de varios
> años.
> Dicho relevamiento físico, implicara ajustar contra el cliente "dedos
> largos" o "donde diablos estaban", para que la contabilidad balancee.
> Saludos: Miguel, La Pampa (RA)
>

> El 19 de mayo de 2012 00:34, Guillermo MDQ <gols...@gmail.com> escribió:
>
>
>
> > Se supone tambien que de tanto en tanto se debe hacer un inventario del
> > stock de mercaderias, asi que el select de consulta se haria con los
> > movimientos a partir de la fecha del inventario en adelante.
>
> > Saludos
> > Guillermo
>
> > El viernes, 18 de mayo de 2012 22:19:34 UTC-3, Miguel escribió:
>
> >> Pero se puede solucionar si se mantienen los movimientos de los últimos
> >> meses (digamos un año) y los anteriores solo con el stock (llamemos le
> >> inicial). De esa manera, reducís la cantidad de registros en la bd, si esa
> >> fuese la preocupación.
> >> Saludos: Miguel, La Pampa (RA)
>

> >> El 18 de mayo de 2012 11:06, Walter R. Ojeda Valiente <w...@hotmail.com>escribió:
>
> >>>  Es muy cierto Daniel, hace unos cuantos años esta forma de trabajar
> >>> habría tenido ese gran "pero", mas los tiempos han cambiado y ahora tenemos
> >>> computadoras rapidísimas y anchos de banda gigantescos entonces ya no es un
> >>> concerniente.
>
> >>> Además, si alguna vez notara que algunos productos tienen muchísimos
> >>> movimientos y las consultas se ralentizan siempre tendría la posibilidad de
> >>> usar una tabla auxiliar con los datos de esos productos y actualizar dicha
> >>> tabla solamente.
>
> >>> Saludos.
>
> >>> Walter.
>

> >>> ------------------------------

> >>> Date: Fri, 18 May 2012 06:40:18 -0500
> >>> Subject: Re: [vfp] Descontar Stock en linea o en lotes

> >>> From: resetsoftw...@gmail.com
> >>> To: publicesvfoxpro@googlegroups.**com<publice...@googlegroups.com>

>
> >>> Hola Walter, el método que utilizadas es excelente ya que nunca darás
> >>> información errónea sobre el stock pero en una aplicación con muchos
> >>> usuarios y varias consultas concurrentes no seria cargar mucho al servidor
> >>> realizando select calculando los movimientos de dicho producto, si dicho
> >>> producto tiene pocos movimientos pues no se notaria pero si hablamos de un
> >>> producto con un historial de varios años y de mucha rotación pues me parece
> >>> que el GBD andaría muy ocupado y podría menguar su performance.
>
> >>> Saludos
>
> >>> --

> >>> Enviado desde dispositivo móvil- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -

[Carlos Miguel FARIAS]

Se presupone que un sistema bien analizado, debe prever un stock mínimo o punto de pedido o reposición. Y también indicado cual es el lote de pedido óptimo. Cuando indicaba de mantener las ventas de varios años atrás, es porque dependiendo del producto, hay estacionalidad, y el sistema debería detectar en función de la fecha si se debe reponer más o menos cantidad de items. Esos items lo debe determinar un gerente de ventas responsable. En la carrera de contador público (y creo que en licenciados en administración) en Argentina son cosas que se enseñan.
Porque se busca no perder ventas si disparar el stock inmovilizado a las nubes.

Saludos: Miguel, La Pampa (RA)

[Manuel Lucas Anaya Guillen]

Este tema es muy interesante, y es indudable que cada empresa puede tener sus propias características.

Pero hay cosas que seran siempre igual en todo lugar:

Por ejemplo: el Balance Contable, no puede ser diferente en Perú, y en Ecuador otro, luego en la China otro.

Las valorizaciones, pueden variar por los metodos aplicados, y este mismo podria ser modificado por la regulaciones propias de cada país.

También la forma de facturar podria variar en algo por paises, pero por lo general hay una logica contable-administrativa que se debe cumplir.

El tema del manejo de un supermercado, sí que es especial.

De hecho pienso que el inventario de saldos va ser la suma de lo que hay en Tienda, vale decir en las gondolas o mostradores que veran los clientes; más las existencia que está en almacén.

Hecha esta precisión luego: El que atiende la venta por telefono, o pedido de un cliente para ser despachado lo hará viendo en el sistema el saldo que hay en Almacén, y por tanto podrá asegurar que lo que está vendiendo tiene mercadería asegurada a ser atendida, pienso que debe ser de inmediato disminuida del saldo, cosa que el que atienda por otra linea vea la existencia menos la cantidad comprometida. De hecho si el comprador por la linea desiste de una mercadería, se borraria de la linea de pedido, al hacer esta operación el programa debería restablecer el saldo de la exitencia en almacén. Para complicar más el programa: Hecho esta reposición, el programa podría avisar al resto de usuarios que estan vendiendo a traves de una ventanita de que ha subido el saldo de la mercadería.

De hecho en el momento en que el comprador confirma su pedido, se actualiza definitamente los saldos en la base de datos, asi como se registra la operación contable de venta.

Lo de la góndola es más simple, la venta de los productos jamas va ser contra un saldo que no exista, porque va ser contra algo que está allí, con el detalle de que:

 a) Al coger un producto el cliente esta dejando en la gondola: existencia menos lo cogido: En el sistema en ese momento no se esta registrando nada, cuando el cliente llega con su carrito, despues de 5, 10 minutos o media hora que empezó su compra, el cajero empieza a facurar la venta, y simplemente da salida lo que lleve, si el cleinte se arrepiente y no compra, anula lo que esta facturando, y al pago, da salida a todo lo que fue aceptado por el cliente, si dejó algun producto se queda allí en caja, para que sea devuelto por el encargo a su lugar.

Pienso que yo lo trabajaría así. Es más de hecho, toda tienda tiene sus procedimientos, y como bien dice Walter,hay que simular lo que esta sucediendo en la practica.

Saludos

--
Manuel L. Anaya Guillén
Warparuna - Huamanguino .... en
Huancavelica, Ayacucho y Apurímac:Territorio Chanka,
--------------------------------------------------------------------------------

"El hombre, en su orgullo, creó a Dios a su imagen y semejanza."  Friedrich Nietzsche