balances on individual tx's wrong in register (was: no subject)

[Linas Vepstas]

--p4qYPpj5QlsIQJ0K
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 03, 2002 at 07:13:01AM -0700, Olaf Faaland was heard to remark:
> Well good, at least it's not just something I did to break my copy.
>=20
> I understand the nature of the problem.  It is a difficult one, at least=
=20
> computationally.
>=20
> I'm actually in the process of trying to understand the register code, wi=
th=20
> the idea that I might attempt to tackle this.  Pat your buddha's belly fo=
r me=20
> some time.

Originally, this was meant to be a 'feature' not a bug. Each split
carries the running balance on the account from which it was drawn, in=20
date-posted order.  I beleive that the register
always shows this balance, irrespective of the sort order, the subset
of splits being viewed, etc.   In other words, the 'balance' is the balance
of the account at the time the transaction was commited.  It is *not*
a running subtotal of the displayed splits.

Note that 'date of entry' is *not* the same as 'date posted'.   The posted
date is supposed to be when the actual flow of money occured.  The date of=
=20
entry is merely the day tht you did the key-wapping. So if you sort
by date-of-entry, you can expect the balances to look goofy.=20

If you "fix" this problem, I suggest leaving the "balance" column alone,
and adding a new column type, called the "subtotal" column.  The
subtotal column would show an always-increasing subtotal of the splits
being displayed (in the ortder that they are displayed).  The balance
column is *meant* to show the account balance, and not the running subtotal.

(I suspect that the documentation, the help, the column labels and
foreign-language translations need to be adjusted to make a careful
distinction between these two concepts).


--linas


>=20
> Olaf
>=20
> On Wednesday 03 July 2002 04:25 am, Derek Atkins wrote:
> > Yes, you're right.  And yes, I can reproduce this problem, but I don't
> > know a good way to _fix_ it.  In short: running balances are HARD.
> >
> > Here's the problem: the register is only a partial view of the
> > account.  For example, you can limit your view to, say, the last 50
> > transactions.  When you change the sort order you change the subset of
> > the account you are viewing.  How do you know the initial balance
> > outside the area you are looking?
> >
> > To take your example, assume you have 3 transactions (let's call them
> > a, b, and c in the "standard" sort order) but you're only viewing 2 (b
> > and c).  In the case of the 'standard' sort order, everything works
> > fine and the running balances are in order (for obvious reasons).
> > However, if you change the order such that you are now viewing, say, b
> > and a, there is no easy way to determine that 'a' was left off.  Now,
> > multiply this to thousands of transactions and you quickly see the
> > problem.
> >
> > Feel free to file a bug report at bugzilla.gnome.org, but honestly I
> > can't think of a good way to support what you want.
> >
> > -derek
> >
> > Olaf Faaland <ofaaland@attbi.com> writes:
> > > Hi,
> > >
> > > I noticed this (running balances wrong in register), too.
> > >
> > > On my machine, I believe it occurred after I switched the display ord=
er
> > > in the register from the default order to "Date Entered", but I hadn't
> > > gotten around to trying to re-create it yet.  I use the xml backend. =
 My
> > > last cvs update was 6/29/02.  I just started using cvs.
> > >
> > > So my steps to re-create just now:
> > >
> > > Created 2 new accounts, "Savings" and "Other Savings", both top-level
> > > bank accounts
> > > Opened a register window for "Savings"
> > > Made the following three entries, in the order given:
> > >
> > > 6/1/02  "Test Entry 1" Other Savings Deposit:$10
> > > 6/2/02  "Test Entry 2" Other Savings Deposit $20
> > > 5/29/02 "Test Entry 3" Other Savings Deposit $30
> > >
> > > Then chose View->Sort Order->Date of Entry.
> > >
> > > Now I get (abbreviated):
> > >
> > > Test Entry 1 : Bal $40
> > > Test Entry 2 : Bal $60
> > > Test Entry 3 : Bal $30
> > >
> > > By the way, perhaps that choice should be labeled "Entry Order" rather
> > > than "Date of Entry", unless the order within a group of tx's entered
> > > within a single day is genuinely not entry order.
> > >
> > > Olaf
> > >
> > > On Saturday 29 June 2002 09:38 am, Eildert Groeneveld wrote:
> > > > balance screwed up?
> > > > in the current cvs head I observe that the balance in an account st=
ops
> > > > accumulating the individual transactions. Has someone else observed=
 the
> > > > same? Secondly, it seems that the total market value of stocks are =
not
> > > > computed any more (share prices are fetched ok from Yahoo).
> > > > Any idea?
> > > >
> > > > greetings
> > > >
> > > > Eildert
> > >
> > > _______________________________________________
> > > gnucash-devel mailing list
> > > gnucash-devel@lists.gnucash.org
> > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>=20
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

--=20
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
PGP Key fingerprint =3D 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933

--p4qYPpj5QlsIQJ0K
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9IyVZZKmaggEEWTMRAlnRAJ4qfz71GOU1zlMG4qgb7PXSD/0e3wCfeCvU
CinU4WbJN2cM81lx0aIF4Aw=
=GxI9
-----END PGP SIGNATURE-----

--p4qYPpj5QlsIQJ0K--