Control de stock

[Jack]

Otra pregunta, modifico una linea de venta y en los eventos de after update y before update, actualizo la ficha del stock del articulo vendido en la linea, parece ser que algún update de la ficha del stock falla, puesto que no refleja el movimiento, en el caso de fallo la grabasción de la ficha del stock, la linea de venta tampoco debería reflejar la modificación, según el funcionamiento de las transacciones. Pero a la práctica no sucede eso, la linea de venta se graba y la actualización del stock no se realiza. Pregunto si esto es cierto o no, y si es así como tiene que funcionar Firebird.
Un saludo Jack.

[Casimiro Notevi]

No se entiende nada del problema que tienes. Pon código y explica exactamente la situación.

[Neftali [Germán.Estévez]]

Me da la impresión de que no estás usando correctamente las transacciones.
Parece que estés usando diferentes transacciones para ambas operaciones. Para comportarse como quieres (según he entendido la pregunta) debes asegurarte de que utilizas la misma transacción para ambas y de que no realizas el Commit o el Rollback hasta que no hayas finalizado ambas.

[Jack]

Hola, la transacción empieza con la linea de venta y acaba con la linea de venta con un commitretaining. ( necesito conservar el contexto ).
Eso ocurre en el programa, en la base de datos ha dos triggers un before update y otro after update que actualizan la tabla de stocks.

Código SQL [-]
create or alter trigger trantes for LineasVentas as begin 
active before update 
update stocks
set ventastotales = coalesce(ventastotales,0) - Old.UnidadesVendidas
where codigostocks = old.codigolineadeventa
end
^
create or alter trigger trdespues fro LineasVentas as begin
active after update 
update stocks
set ventastotales = coalesce(ventastotales,0) + New.UnidadesVendidas
where codigostocks = new.codigolineadeventa
end

En la transación hay implicada una segunda tabla que es la de stocks, donde se guardan los totales de los movimientos por cada codigoarticulo, es decir va haciendo el stock a medida que va modificando lineas, también existe el trigger insert y delete con la misma estructura. Yo creo que la transaccion es única aunque se vean implicadas dos tablas. Para mi si la linea de ventas recoge la modificación obligatoriamente la tabla de stocks debe de hacer correctamente los dos updates. La transacción la inicia la linea de ventas y la acaba la linea de ventas.
La pregunta es porque este mecanismo no es seguro ?, en caso de fallo del update en la tabla de stocks debería también fallar la actualización de la tabla de lineas de ventas, esto es cierto. Lo que me ocurre es que no me actualiza el stock pero si acualiza bien la tabla de ventas. Utilizo los IBX de delphiXE2. LLevo años sin comprender este funcionamiento, a ver si alguien lo entiende y me lo puede explicar.
Gracias.

[Casimiro Notevi]

Si no he entendido mal, si antes de actualizar las restas, y después de actualizar las sumas... te quedas igual que estabas

[Jack]

Hola, en la linea de venta tengo 10 y modifico a 25. Es decir resto 10 ( old.unidadesventa), y sumo 20 ( new.unidadesventa ).
Gracias.

[Casimiro Notevi]

¿Pero por qué restas lo que hay, si ya estarán contadas?

[Jack]

La última pregunta no la entiendo, el hecho de primero restar y luego sumar es porque se puede cambia el codigo de articulo de la linea de venta si el articulo AA tenia 10 unidades, y modifico al articulo BB 20 unidades. la resta deja los AA en 0 y la suma pone los 25 en BB que es lo que tiene que haber.
Gracias.

[Casimiro Notevi]

El stock se modifica cuando se compra y cuando se vende. Además se puede hacer un inventario manual para ajustarlo por posibles problemas, errores, etc.
Si compro, sumo al stock.
Si vendo, resto del stock.
Si hago inventario, pongo una cantidad fija.
No entiendo lo que dices de pasar stock de AA a BB. ¿Pasas 3 libros de matemáticas a 5 lápices de colores?

[Jack]

Hola, solo estoy vendiento, he vendido 10 lapices pero me he equivocado y en realodad son 25 colorines, lo que hago es modificar la linea de venta sustituyendo lo 10 lapices por 25 colorines. Solo es eso.
Gracias

[Casimiro Notevi]

Entonces no estás haciéndolo correctamente.
Piensa con lógica, ejemplo, has vendido 10 caramelos y querías vender 20 lápices.
Para solucionarlo tendrás que vender -10 caramelos.
Luegos venderás los 20 lápices.

[juanelo]

Y pensaba que lo habia visto todo . Como dice Casimiro, tu problema esta en la logica, revisa el proceso y la iteraccion que tiene el usuario.

[mamcx]

Jack: Te recomiendo que estudies sobre el tema, y uses una hoja de excel (o lapiz y papel) y paso a paso vayas haciendo el proceso. Si no tienes claro lo que haces, no podras programarlo.

[Casimiro Notevi]

Empezado por mamcx

Jack: Te recomiendo que estudies sobre el tema, y uses una hoja de excel (o lapiz y papel) y paso a paso vayas haciendo el proceso. Si no tienes claro lo que haces, no podras programarlo.

Totalmente cierto.
Yo siempre tomo papel y lápiz. Pienso en el proceso en la vida real. Lo describo siguiendo paso a paso cada opción. Cuando lo tengo resuelto en la "vida real" es entonces cuando enciendo el ordenador y lo tecleo en el lenguaje de programación que esté usando.

[TiammatMX]

Empezado por mamcx

Jack: Te recomiendo que estudies sobre el tema, y uses una hoja de excel (o lapiz y papel) y paso a paso vayas haciendo el proceso. Si no tienes claro lo que haces, no podras programarlo.

Regla CERO del diseño de sistemas: Si no entiendes PERFECTAMENTE el proceso a programar, no hagas nada, por mucha presión que exista.

Si le explicas a tu abuela el proceso y ella aporta ideas, estás listo para comenzar a codificar.

[Casimiro Notevi]

Empezado por TiammatMX

Regla CERO del diseño de sistemas: Si no entiendes PERFECTAMENTE el proceso a programar, no hagas nada, por mucha presión que exista.

Si le explicas a tu abuela el proceso y ella aporta ideas, estás listo para comenzar a codificar.

[Jack]

Que nadie comprenda lo que digo me hace alucinar, vuelvo a explicar que el usuario de mi programa ( no yo sino el usuario que quede bien claro ), graba una linea de venta de 10 lapices, despues una vez ha grabado la linea y descontado el stock de la ficha de lapices, rectifica la linea porque en realidad tenia que haber grabado 20 libretas( vuelvo a decir que el usuario se ha equivocado él y no yo ).
Si esta situación vuestros clientes no la tienen los mios si, y mi deber es que se puedan gestionar estos cambios en la base de datos con lo que nadie de vosotros tiene el derecho de opinar si mi pregunta es buena o mala, tan solo se pide que el que no la comprenda o no la sepa pues que no la conteste, decirme 'que le pregunte a mi abuela no se que', o que 'creía que lo había visto todo' esta totalmente fuera de lugar y es de muy mala educación ya que mi abuela esta ya fallecida.
Creía que esta página era para ayudarnos entre gente que trabaja con firebird, y que sufrimos lo indecible por intentar hacer bien las cosas pero veo que no.
No sé exactamente desde que año estoy suscrito a esta página, son muchos años y muchos años también trabajando con firebird, nunca jamás se me habría ocurrido contestar a nadie de la manera que aquí se me ha contestado. Una buena noticia para todos estos que me lo han hecho, esta sera la última vez que entre en esta página, jamás volveré a pisar los pies por aqui.
Es triste encontrase con gente así por la vida, aunque tengo claro que siempre que tenga que medirme con gente de este tipo, yo estaré infinitamente por encima de ellos, por respeto a los demas y por educación.

[Casimiro Notevi]

Hay que ser más humilde, no pasa nada por reconocer que te has equivocado, todos lo hacemos y ninguno nacemos enseñados, se aprende de los errores.
En tu explicación del problema está claro, y así se te ha informado (con bromas sarcásticas, cierto) de que el planteamiento que haces es incorrecto. ¿Y te enfadas porque te han dicho que está equivocado el planteamiento que haces?, yo me alegraría que me dijeran que está mal y así poder solucionarlo.


PD. En relación a tu otro mensaje de baja, basta con que no nos visites más. Suerte.

[[Lepe]]

Jack... lo siento por como te has tomado todo...

El problema que tienes es de concepto, es muy fácil de solucionar y no tiene nada que ver con Firebird, me explico:

Tu haces la interfaz con un ClientDataset, un StringGrid, pero no uses un DBGrid.
Dejas que el usuario haga todos los cambios que desee, pero tu transacción solo empieza cuando el usuario le da al botón "Aceptar".

Mientras tanto el usuario puede modificar su línea, sus cantidades, todo lo que quiera, eso lo "hace en memoria", no pasa por la Base de datos. Una vez que él lo tiene claro y pulsa "Aceptar", es en realidad cuando empieza la transacción se suma ó se resta y se acabó.

Tu error que no terminas de comprender es que el trigger beforepost y afterpost se ejecutan siempre que guardes en la tabla. Ejemplo:
"quiero vender 20 lápices" con tus triggers haces lo siguiente:

- Empieza la modificación, usuario vende 20 lapices y pulsa botón aceptar:
- trigger before post: stock.ventastotales = coalesce(ventastotales,0) - 20
- trigger after post: stock.ventastotales = coalesce(ventastotales,0) + 20
- Se hace el Post y después CommitRetainig. Todo queda grabado.

¿cuanto lápices te quedan en stock.ventastotales? Lo mismo que tenías antes de empezar. Eso es lo que todos te han dicho ya.

Me da la impresión que usas un DBGrid y cuando alguien graba una línea del grid haces el post y el commitRetainining, por eso te falla la lógica del negocio. Todo eso que el usuario "se equivoca"... esos errores que comete el usuario los hace "en memoria", en un stringGrid, sin pasar por la Base de datos!!!, o al menos así debe ser!!! ¿lo entiendes ahora?


Si el usuario se ha equivocado y ha pulsado el botón Aceptar. Lo que debe hacerse es un apunte rectificativo (no tiene nada que ver contigo ni con programación). Es él, el que debe añadir otro apunte a la tabla stock con concepto "anulación/rectificación en el apunte con ID=33" y en cantidad pone "-20" (si vendió 20 unidades, en este apunte pone que ha vendido "-20" y rectifica los totales de stock). Queda grabado en el sistema que él se equivocó y después lo corrigió.

Saludos

[mamcx]

Empezado por Jack

Que nadie comprenda lo que digo me hace alucinar...

Aunque tomaste una accion drastica, no debería sorprenderte que no te comprendan, y a la vez, que el programa no funcione. Ambos problemas son el mismo problema..

Definir el problema es como tener el 90% de la solución. Entender el problema es la puerta segura y facil al éxito.

Por ejemplo, de acuerdo al zen de python:

Explicito es mejor que implicito
---
Al enfrentar la ambigüedad, rehusa la tentación de adivinar.
---
Si la implementación (osea, código) es difícil de explicar, probablemente sea una mala idea

Probablemente estas familiarizado con la idea que es dificil de estimar cuanto cuesta/dura un programa, que las especificaciones que te dan los clientes siempre son insuficientes, o que cuando vas a implementarlas te das cuenta que tienen lagunas.

Una razon? Porque si las especificaciones fuera realmente correctas y completas, no solo no tendrían ambigüedades sino que serian la explicación exacta y detallada del programa.

Un programa entonces, seria la explicación (en términos del lenguaje) concreta de la especificacion.

----

En pocas palabras: Cuanto tienes las preguntas claras, y son claras PRECISAMENTE PORQUE CUALQUIER LAS PUEDE ENTENDER, ERGO, LAS PUEDES PROGRAMAR Y EL LENGUAJE LAS "ENTENDERA".

Eso es especificamente, la labor que se hace en foros como este. Aqui NO DAMOS RESPUESTAS, no porque no queramos, sino porque muchas veces no podemos! (literalmente!)

Porque? Porque NO ENTENDEMOS LA PREGUNTA! Si la entendemos, tendremos las respuesta, y al MISMO tiempo, la tendrias tu