Possible bug in assertions

54 views
Skip to first unread message

Craig Earls

unread,
Jan 3, 2013, 12:44:41 PM1/3/13
to ledge...@googlegroups.com
I can't decided whether this is a bug, or a misunderstanding on my part.

I have had a few cases recently where a balance assertion was acting strangely.  It appears that The postion of the assertion in the file stream is more important than its chronological position.

I am trying to generate a suitable toy example, but here is a word description:

If an assertion for a balance on 2012/12/31 is in a file that is included prior to a relevant transaction WITH AN EARLIER DATE. the earlier transaction is calculated as if it were after the assertion.

--
Craig, Corona De Tucson, AZ
enderw88.wordpress.com

Gabriel Kerneis

unread,
Jan 3, 2013, 12:59:55 PM1/3/13
to ledge...@googlegroups.com
On Thu, Jan 03, 2013 at 10:44:41AM -0700, Craig Earls wrote:
> The postion of the assertion in the file stream is more important than its
> chronological position.

I think this has been acknowledged by John on this mailing-list in the past (but
cannot find it right now).

Best,
--
Gabriel

Christophe Rhodes

unread,
Jan 3, 2013, 3:34:34 PM1/3/13
to ledge...@googlegroups.com
Craig Earls <ende...@gmail.com> writes:

> If an assertion for a balance on 2012/12/31 is in a file that is included
> prior to a relevant transaction WITH AN EARLIER DATE. the earlier
> transaction is calculated as if it were after the assertion.

So, this makes sense to me (believe it or not), and I use it as a
feature. My bank sometimes sends me credit card statements with a given
statement date, and then in subsequent months sends me new statements
with transactions with dates preceding the previous statement's dates,
probably because it has taken some time for a transaction to work its
way through the system, but once it has its effective date was the date
that I paid for something.

The transactions then go in ledger files in statement order, and balance
assertions work as I (but not you :-) expect them to work; on the other
hand, sorting by date gives the what-retroactively-actually-happened
story. (Given that transactions can have multiple dates, and that
there's no enforced policy on what the dates mean, I don't think that
there's anything else that a balance assertion can mean other than
through file position).

That's my thinking, anyway.

Christophe

Craig Earls

unread,
Jan 3, 2013, 5:22:36 PM1/3/13
to ledge...@googlegroups.com
Isn't that what the effective date notation is for?

thierry

unread,
Jan 3, 2013, 6:05:44 PM1/3/13
to ledge...@googlegroups.com


On Thursday, January 3, 2013 6:59:55 PM UTC+1, Gabriel Kerneis wrote:
On Thu, Jan 03, 2013 at 10:44:41AM -0700, Craig Earls wrote:
> The position of the assertion in the file stream is more important than its
> chronological position.

I think this has been acknowledged by John on this mailing-list in the past (but
cannot find it right now).

Craig Earls

unread,
Jan 3, 2013, 6:13:30 PM1/3/13
to ledge...@googlegroups.com
Look at that, I even helped answer the question...Thanks thierry!

John Wiegley

unread,
Jan 3, 2013, 9:44:57 PM1/3/13
to ledge...@googlegroups.com
Yep, assertions are done by ordering, not by time.

John
Reply all
Reply to author
Forward
0 new messages