Columna Saldo de Cuenta Corriente

On Sun, 15 Jul 2007 15:24:35 -0400, principiante wrote:

Si eso tiene que ser posible entonces el saldo por movimieno no
tiene ningún sentido.

Por supuesto que no lo tiene, debiste darte cuenta mucho antes de plantear
esa idea tan descabellada.

Una transacción tendrá una fecha a la que se refiere en el mundo
real pero también representa un transacción en el sistema, que
también tiene una fecha.

Deberias leer algo sobre temas contables... ufff.

De contabilidad ni idea! Ni me interesa. Pero yo he trabajado en
dos sistemas de contabilidad que para cada movimiento tenían una
fecha de introducción en el sistema y otra de referencia a la
transación. Estos movimientos no se podían cambiar y errores solo
podían corregirse con nuevos movimientos.

O cuando los contables apuntaban estas cosas ordenadamente en
sus libros cuando llegaba una factura 2 días demasiado tarde
metían un renglón en medio de los que ya tenían y corrían el resto
hacia abajo? Sería un poco estúpido eso.

Pues es exactamente asi como se hace en muchos (quizas la mayoria) de los
sistemas contables.

Vamos, que sí son estúpidos estos sistemas.

introducir nuevos movimientos con correcciones o de no exigir que
estas tengan un orden total y fijo en el tiempo, sería:

24 enero 21:00 horas
Cliente a Servidor: Dame el saldo actual de la cuenta X
Servidor a Cliente: 234,00
25 enero 13:00 horas
Cliente a Servidor: Dame el saldo del 24 de enero a las 21:00 horas
de la cuenta X
Servidor a Cliente: -23,00

Puede alguien explicarme que valor informativo de este dato?

Precisamente por eso es un sinsentido tratar de hacer lo que propusiste.

Mi primera reacción en este hilo:
Añado un campo 'num' porque puede haber varios registros con la
misma fecha.

Asumiendo que:
- la combinación (fecha,num) es única
- que la tabla solo tiene una cuenta
- debe y haber no pueden tener nulos


select a.fecha, a.num, a.concepto, sum(b.debe - b.haber) as saldo
from cuenta a inner join cuenta b
on a.fecha > b.fecha or (a.fecha = b.fecha and a.id >b.id)
group by a.fecha, a.num, a.concepto
-
(al final lo de 'id' fue una equivocación y tiene que ser 'num')

Por qué crees que he introducido el num? Para forzar un orden total
y darle sentido al running saldo. Y todo el tiempo asumiendo que la
fecha es un timestamp del sistema y que lo que se ha introducido es
definitivo.

Después vienes tu y hablas de actualizar fechas, borrar movimientos,
etc, etc.

Entonces doy aquí un ejemplo de que si eso puede ser, el running
saldo va a ser un sinsentido. Lo calcule el sgbd, el reporte, la
aplicación o mi abuela.

Y tu conclusión ahora es que lo que yo propongo es un sinsentido!

Venga ya hombre... vete a tomar el fresco, que te hace falta.

Concluir, desconfiar que hay confusión es una cosa, pero otra muy
distinta es que lo que yo propongo es lo que sí es un sinsentido.

Eso aparte de que: sql reporting también sabe sumar, que si el ERP
enseña mucho a principantes con tu y yo, que si sabelotodismo,
sabelotodo, ..., etc, etc, etc.

Por cierto... son muchas las cosas de las que no tengo ni idea,
pero principiante lo serás tu!

Lo dicho a tomar el fresco.

"Carlos M. Calvelo" escribió en el mensaje
news:

De contabilidad ni idea! Ni me interesa. Pero yo he trabajado en
dos sistemas de contabilidad que para cada movimiento tenían una
fecha de introducción en el sistema y otra de referencia a la
transación.
Estos movimientos no se podían cambiar y errores solo
podían corregirse con nuevos movimientos.

Hay sistemas que son asi pero son muy rigidos por ejemplo para pymes.

Pues es exactamente asi como se hace en muchos (quizas la mayoria) de los
sistemas contables.

Vamos, que sí son estúpidos estos sistemas.

No lo creo.
Eso se da igual con las existencias y los costos en sistemas de control de
existencias de almacen y en general en cualquier sistema donde hay que
mantener saldos y movimientos de altas y bajas.
Ponte a pensarlo.
Yo creo que lo estúpido es no entender las necesidades de los usuarios, pero
el termino no va a los sistemas sino a los analistas.

Precisamente por eso es un sinsentido tratar de hacer lo que propusiste.

Mi primera reacción en este hilo:
Añado un campo 'num' porque puede haber varios registros con la
misma fecha.
Asumiendo que:
- la combinación (fecha,num) es única
- que la tabla solo tiene una cuenta

- debe y haber no pueden tener nulos


select a.fecha, a.num, a.concepto, sum(b.debe - b.haber) as saldo
from cuenta a inner join cuenta b
on a.fecha > b.fecha or (a.fecha = b.fecha and a.id >>b.id)
group by a.fecha, a.num, a.concepto

-

(al final lo de 'id' fue una equivocación y tiene que ser 'num')

Hasta ahi no es un sinsentido, ni yo lo he satanizado en principio, es solo
una consulta que algunos pensamos que podria ser muy lenta cuando hay muchos
registos, salvo ver los planes de ejecucion como dije en otro mensaje.

Por qué crees que he introducido el num? Para forzar un orden total
y darle sentido al running saldo. Y todo el tiempo asumiendo que la
fecha es un timestamp del sistema y que lo que se ha introducido es
definitivo.


Después vienes tu y hablas de actualizar fechas, borrar movimientos,
etc, etc.

Hablo de eso porque no se puede programar pensando que las cosas son
estáticas a menos que sea un requisito del diseño. Si llega a serlo pues te
sacaste la lotería pero no creo que eso se dé mucho en sistemas que manejan
saldos.
De la misma forma que no podemos programar pensando que habrá siempre pocos
datos.

Entonces doy aquí un ejemplo de que si eso puede ser, el running
saldo va a ser un sinsentido. Lo calcule el sgbd, el reporte, la
aplicación o mi abuela.

Y tu conclusión ahora es que lo que yo propongo es un sinsentido!

Venga ya hombre... vete a tomar el fresco, que te hace falta.

Me ire a tomarlo:) pero eso no quita que poner un saldo en un registro de
movimiento sea un sinsentido habiendo otras opciones, incluida tu consulta,
aun con las suposiciones que hiciste.

Concluir, desconfiar que hay confusión es una cosa, pero otra muy
distinta es que lo que yo propongo es lo que sí es un sinsentido.

Es lo que yo creo y lo sigo creyendo, pero hombre... no hay a llorar por
eso.
Vete a tomar fresco que lo necesitas mas que yo parece :)

Por cierto... son muchas las cosas de las que no tengo ni idea,
pero principiante lo serás tu!

Soy principiante y me siento orgulloso de serlo; y cierto que tampoco trato
de opinar y "sabelotodizar" de cosas que desconozco ni tratar de
menospreciar a los demas.

Lo dicho a tomar el fresco.

Despues de vos.


Jose TH

On 16 jul, 00:52, "principiante" wrote:

Hasta ahi no es un sinsentido, ni yo lo he satanizado en principio, es solo
una consulta que algunos pensamos que podria ser muy lenta cuando hay muchos
registos, salvo ver los planes de ejecucion como dije en otro mensaje.

Es lenta y no es la culpa de la consulta, sino del optimizador, que no
se entera. He propuesto mas tarde buscar otras alternativas basándose
en no poder borrar ni cambiar movimientos.

Me ire a tomarlo:) pero eso no quita que poner un saldo en un registro de
movimiento sea un sinsentido habiendo otras opciones, incluida tu consulta,
aun con las suposiciones que hiciste.

Qué opciones? Si el calculo no tiene sentido, no tiene sentido.
O tiene mas sentido si se hace muy rápido y en otro lado?
Y es de lo que estas discutiendo. Yo que si con esas condicones
(poder borrar, actualizar) no tiene sentido y tu que si puede
ser mucho mas rápido en otro lado.

Un poco mas de fresco quizás?

>Si se hace en triggers, vistas materializadas o como sea
>ya es otro problema.

No opino sobre eso porque ni me pasaria por la mente nunca ese tipo de
calculo "ad-hoc".


El saldo actual después de introducir un nuevo movimento, en orden
de introducción en el sistema, es el saldo anterior + el saldo del
moviminto que se introduce. Qué tiene eso de ad hoc?

Habra que buscar un diccionario.

Dónde dije yo eso?
Estoy empezando a dudar si sabes leer porque no dejas de atribuirme
cosas que no he escrito.

Yo no se leer?! Esa ofensa gratuita pues analfabeto seras tu. Por lo
menos escribes muy mal porque despues niegas lo que escribes y tampoco
entiendes bien lo que lees.

impresion que lees muy rapido.

Si si, ya los he leído. Te refieres a algo en particular?

Por cierto... son muchas las cosas de las que no tengo ni idea,
pero principiante lo serás tu!

Pues aqui quien mas parecio ser un principiante fuiste tu. y no creo que el
principiante sea tan principiante puesto que sin tener que ofender ni
acusarte de analfabeto, terminó dandote clase.