transaction sorting is not irrelevant?

[Jeroen De Vlieger]

; bug report
; the following script throws an assertion error.
;
; I would expect ledger to parse the journal and process the transactions in order of date.
; this would mean that the assertion transaction gets processed after the two entry transactions and hence would pass gracefully.
; This appears to not be the case though :-s



2012/10/08 entry
  a  € 1
  y

2012/10/10 assertion
  a  € 0 = € 2

2012/10/09 entry
  a  € 1
  z

[Craig Earls]

ledger parses the journal in the order in which it comes.  The case you brought up is one of the few in which order is actually important to the results of the calculations at the end.

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

[John Wiegley]

>>>>> Jeroen De Vlieger <fly...@gmail.com> writes:

> ; I would expect ledger to parse the journal and process the transactions in
> order of date.

There are many times when I would have liked this as well, but it is MUCH more
complicated than it sounds. :)

John

[Christophe Rhodes]

I think it needs at least an option not to; my use case for parsing in
textual order has transactions with dates relevant to me, interspersed
with assertions at the bank's statement date. (It is mildly common for
transactions to "cross", as it were, with the statement, so that the
statement date comes after some transactions labelled with my dates that
are not accounted for in that statement).

Cheers,

Christophe

[Zack Williams]

> I think it needs at least an option not to; my use case for parsing in
> textual order has transactions with dates relevant to me, interspersed
> with assertions at the bank's statement date. (It is mildly common for
> transactions to "cross", as it were, with the statement, so that the
> statement date comes after some transactions labelled with my dates that
> are not accounted for in that statement).

It may be simpler to write a script that reorders the input file in date order.

- Zack

[Craig Earls]

That is actually trivial:

ledger -f original --sort d print >> datesorted

I use that to clean up my ledger files periodically.

[Jeroen De Vlieger]

So It is not a bug then?
Transactions are parsed *and* processed in the order that they appear in the journal file?

Does this also mean that the ledger program assumes that the journal is correctly ordered?
I.e. when using the -e  <date> flag, will ledger stop parsing once it encounters a transaction with a later date assuming that all the following transactions are will also be at a later date?

In general when using time related flags like -M, -b, -e, ... Does ledger make any assumption about the order of the transactions?
I.e. should I worry and be extra careful to make sure my transactions are in order or is that a waste of time?

with kind regards,
Jeroen

[Craig Earls]

Once the transactions are parse the time related functions can prune the transactions that are allowed to contribute.

You should ensure any "directive" transactions, like automatic transactions, or consistency transactions occur earlier in the file than they are needed.  Think of the input file as source code to a compiler.  The dates are more like labels than line numbers.

You don't really need to worry about the date order in most cases.  I just throw transactions in and once a week or so clean up the files using the "print --sort d" command which also makes the transactions more regular in format. I don't worry about that when I am entering them.  I keep directive commands in a separate file that the print command never sees.

[John Wiegley]

>>>>> Jeroen De Vlieger <fly...@gmail.com> writes:

> So It is not a bug then? Transactions are parsed *and* processed in the
> order that they appear in the journal file?

Yes.

> Does this also mean that the ledger program assumes that the journal is
> correctly ordered? I.e. when using the -e  <date> flag, will ledger stop
> parsing once it encounters a transaction with a later date assuming that all
> the following transactions are will also be at a later date?

No, the -e flag is applied only after all transactions have been read in.

> In general when using time related flags like -M, -b, -e, ... Does ledger
> make any assumption about the order of the transactions? I.e. should I
> worry and be extra careful to make sure my transactions are in order or is
> that a waste of time?

No, you only need ordering for constructions within the data file (balance
assertions, pricing relationships, etc). In most other ways, ordering in the
data file has no effect on reporting. Some reports, like -M, even internally
sort if the data has not yet been sorted.

John

[Jeroen De Vlieger]

It's always been implied,  but allow me to say it explicitly for once:

Thanks for all the timely and informative feedback!

This project and its community seems to be alive and kicking ;-)

Jeroen