Ver Mensaje Individual
  #13  
Antiguo 16-01-2009
Avatar de AzidRain
[AzidRain] AzidRain is offline
Miembro Premium
 
Registrado: sep 2005
Ubicación: Córdoba, Veracruz, México
Posts: 2.914
Reputación: 21
AzidRain Va camino a la fama
Nadie ha acotado que en este caso, el nuevo cálculo del citado campo solo será válido para los registros que se introduzcan posteriormente ya que tooooooodosss los registros que ya estaban en la base de datos ahora mostraron un resultado incorrecto.

Ejemplo de este efecto:

El famoso IVA (en México del 15% sobre el subtotal de la factura). Si ponemos para más facil un campo calculado llamado IVA que sea igual a SUBTOTAL*0.15 funciona bien, y asi podemos capturar nuestras facturas sin mayor problema, peeeero....un buen día dicho impuesto cambia y ahora es de 16% (ni lo mande Dios). Como somos muy duchos vamos y cambiamos el campo calculado para que ahora haga SUBTOTAL*0.16 y ohhhhhh ya no cuadra nada de lo que teniamos previamente almacenado!!!!! ya que el nuevo cálculo es con 0.16 y lo que teniamos se dió por hecho que era por 0.15.

Ojo: No utilicen campos calculados en valores que NO DEBEN VARIAR CON EL TIEMPO, es decir, valores que una vez capturados ya no se pueden modificar. En mi ejemplo el IVA de una factura es precisamente el que se cobró al momento de su elaboración y ningún otro. Es decir, no utilicen campos calculados si alguno de los valores involucrados es una "constante" al momento de hacer la operación. De esta forma, si podemos hacer un campo calculado para que nos saque el importe de una partida (CANTIDAD * PRECIO UNITARIO) ya que ambos datos ya no cambiarán una vez hecha la factura, es decir, tanto CANTIDAD como PRECIO UNITARIO son dos campos que se guardan en la tabla y ya no se veran afectados externamente.
__________________
AKA "El animalito" ||Cordobés a mucha honra||
Responder Con Cita