> > does it right now go in the order they were entered?  What about adding an
> > optional ordering within each day, where put either the credits or the debi
ts
> > first within that day.
> 
> Doesn't the engine store the transaction time in seconds since 1970?  If this
 is
> the
> case, what is the default value used for a transaction when just the date is
> specified?  
> Is it noon?  Midnight?  Instead of adding a different set of rules for
> transactions 
> within a day, would it make sense to use the time within a given day to
> determine the 
> sort order.  Then the engine could take care of the sort order.  Default each
> transaction
> to occur at noon, and let the user bump transactions forward or backwards a
> little if
> necessary to determine the sort order.

The problem is that _that_ date/time is _fairly worthless,_ as it represents 
the time at which the transaction is _entered._  Which could represent a 
_third_ point in time.  We thus have _three_ times:

a) The moment at which you incurred the transaction,
b) The moment at which the effects of the transaction hit your bank account, 
and
c) The moment at which you typed in the transaction.

All three being legitimately different.

I would think c) to be the least meaningful of the three.

By the way, another moment that I _would_ consider of some value would be the 
moment at which the split was marked as "reconciled as clear."  (To connect 
this to the other discussion about Reconciliation...)

I have had occasion to care about this; with an account that had _hundreds_ of 
transactions per month, it became a matter of some importance to be able to 
trace back to know which month the transaction cleared the bank.

This was on paper, so what I'd do was to use a different symbol each month to 
mark items as "reconciled."

I could then look back at the books, see which symbol was used, and infer, 
from that, which bank statement the item came from.  It's mostly important 
when transactions commonly remain outstanding for several months, which isn't 
particularly important to the average home user.
--
cc hello.c, in Canada, results in:
  eh.oot
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>



--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]


Reply via email to