IsModified y Triggers

Hola, tengo un tema con los “cálculos arrastrados” que nos enseñó vERP el cual involucra la función IsModified y los Triggers. Explico mi caso.
Como comenté, tengo una tabla que está basada en el concepto de “cálculo de arrastrados” para llevar mis inventarios.
Tomando como referencia una cadena de fichas comunes por EMP, ALM, ART y ordenadas por fecha y hora es como se calculan los arrastrados. Si tomo alguna ficha, la que sea, excepto la final y le cambio la fecha hacia una más reciente, y a partir de ahí calculo los arrastrados, todos los registros posteriores a la fecha original que tenía la ficha van a quedar desactualizados.
La solución sería, guardar la referencia del registro anterior al modificado y a partir de ahí calcular los arrastrados, pero para que se haga correctamente tengo que esperar a que la ficha modificada haya sido, pues modificada (que ocupe su nuevo lugar en la cadena) para que el cálculo del arrastrado sea efectivo.
Y aquí es donde vienen mis dudas.

  1. ¿IsModified me servirá en el trigger “Posterior a una modificación”?
  2. Las variables que declaro en una tabla, ¿Permanecen su valor entre Triggers? es decir, ¿el valor que asigne a una variable en el “anterior a una modificación” lo puedo leer en el “posterior a una modificación”?

Saludos cordiales.

Cálculos arrastrados…
Fecha1 Valor1 Saldo1
Fecha2 Valor2 Saldo2 (Saldo1 + Valor2)
Fecha3 Valor3 Saldo3 (Saldo2 + Valor3)
Fecha4 Valor4 Saldo4 (Saldo3 + Valor4)

Si estos valores tienen comunes en EMP, ALM, ART, entonces deberías de agregar dentro del Indice, también la fecha, pero sin ser común, con esto, se controlaría o agruparía por 3 comunes y ordenar por la fecha, con esto, si se ejecuta un proceso de re calcular ya debería de quedar correcto.
Otra opción, y es la que usaba, era utilizar hermano continuo, con el mismo indice, 3 comunes mas fecha y hora para que mantenga el orden, y con ello mediante formula de Saldo_Anterior.Saldo + ValorX me da un saldo, y si por ejemplo: la modificación de fecha pasa a ser Fecha2, entonces = Saldo_Anterior.Saldo + Valor2 = Saldo2, con esto Saldo_Anterior pasa a ser Saldo1.
Con esto no hace falta ningún triguer, ya que al ser de tipo formula se estaría ejecutando constantemente.
EL Stock en Ficha de Producto siempre se debería de ejecutar correctamente mediante Actualizaciones, ya que al modificar Fecha, no varia la cantidad, solo el orden en el que se muestran los datos…

Gracias figaricarlos.
Imagina que a la ficha que está en fecha2, le cambias la fecha y lo dejas después de fecha4,
las fichas de fecha3 y fecha4 ni se enteran y no se actualizan, por lo que de alguna manera tengo que dejar la referencia a la ficha de fecha1 para que: primero asegurarme que la ficha de fecha2 haya sido modificada primero (si en este momento corro el recalculo sería a partir de esta ficha y el anterior pues ya tendría un saldo incorrecto), pero la corrección definitiva vendría después de recalcular del anterior a la ficha movida. Como necesito obtener la referencia del registro anterior, ya vi que no me conviene hacerlo a través de triggers, solo debo de tener control de modificar todo el código que me haga el cambio de fecha (afortunadamente solo es en un solo lugar).
Al final, debido a que esta ficha no “acumulaba” hasta que había una condición, al moverlo de fecha no me generó problema, porque el cambio de fecha viene acompañado con la condición para que “acumule”. El problema ya vi que está en el proceso de “actualización” en la tabla donde llevo el control de existencias por almacén ya que descontó/acumulo dos veces y la existencia que me marcaba la última ficha de movimientos contra lo que está en la tabla EXS_G. Afortunadamente esto se corrige corriendo un recálculo, pero mientras tengo el error.
Al ser una actualización es un poco más complicado de seguir, pero ya estoy trabajando sobre eso.

Un poco complicado el tema, solo para finalizar y cerrar.
En mi caso, existe un movimiento el cual debe de tener unas autorizaciones, si no, no se toma en cuenta. El tema, es que el procedimiento de cálculo de existencias, que está basado en el vERP hasta donde creo, primero hace el cálculo de arrastrados y toma en cuenta la condición para sumar o no al stock arrastrado. Luego para llenar la tabla EXS_G no toma en cuenta la condición y suma/resta y de ahí es que venía mi descuadre.
Un caso muy particular, pero quise compartir mi solución para dar por cerrado este tema.

2 Me gusta