On 01 May 2000 22:06:07 CDT, the world broke into rejoicing as
John Hasler <[EMAIL PROTECTED]> said:
> Christopher Browne writes:
> > 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.
>
> I would think that c) is the most meaningful of the three. It is likely to
> be the most accurate available record of the date on which you recognized
> the transaction, and it is the date and time that, when used to sort the
> transactions, is likely to be least surprising to the user.
>
> It is also the only one of three that is always available.
Sorry, I don't think so. If I go on vacation to Nepal for 2 months, and
don't get around to entering information 'til I get back, the backlog
doesn't affect the fact that the two months worth of credit card charges
hit accounts whilst I was away.
I've done "box jobs" where _all_ the transactions for the year were entered
at one time, at the end of the year. When I do that, all transactions might
be dated on one single day.
It is _certainly_ reasonable to track entry date; that is _highly_ useful
from an audit point of view.
But when the issue is of how to allocate transactions over time, which will
include their allocation to particular accounting periods, time of data
entry is decidedly _not_ an acceptable measure.
I could, if pressed, outline some entertaining _frauds_ that could be
implemented via the methodology of not recognizing transactions until
they are entered into the computer system. Tax authorities like the IRS
and CCRA would _not_ be pleased with this approach, suffice it to say...
--
The way to a man's heart is with a broadsword.
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
