Document directives rendered at the end of the day

[Filippo Tampieri]

I mostly use document directives for monthly statements and other periodic statements (e.g. payroll) and like to use the date of the last day of the period for the directives and for the filename of the filed documents.

Unfortunately, this means that when I render a journal in bean-web, the document line for a monthly statement may appear before some of the transactions for that month (any transactions that happened on the last day of the period). I find this a bit annoying, so I am looking for ways to correct this.

Here are the options I am seeing:

1. Make beancount.core.data.SORT_ORDER customizable to that I could achieve my goal by changing

   SORT_ORDER = {Open: -2, Balance: -1, Close: 1}

   to SORT_ORDER = {Open: -2, Balance: -1, Document: 1, Close: 2}

2. Make it possible to disable sorting of the entries after the custom plugins have run and write a plugin to reorder the directives at the end of the pipeline;

3. Write a plugin that adds one day to the date of all document directives.

I like option 1 the best; it would end up being a one-liner in a user's .import file if Martin choses to implement it.

Option 2 is convoluted and possibly error prone, and still requires changes to the beancount source, so I do not think it is such a great idea.

Option 3 is what I may do while waiting to see how this thread gets resolved; note, though, that the result is not exactly like that of Option 1; Option 3 will result in document lines appearing after balance lines of the same date. I may live with it for a while, but it is not great. In my mind, the documents complete a billing period while the balance line both completes one period and starts a new one, so it logically would come after the documents.

Any thought?

[Filippo Tampieri]

Well, there is always Option 4.

Option 4 is to write a plugin that changes the map used by beancount to determine the sort order for the entries. Since entries are resorted after all plugins are done, we get exactly the result we wanted. I admit that this is a bit of a hack since it goes under the hood of beancount and is not guaranteed to keep working if the implementation were to change.

If you want to give it a spin, you can find the plugin at

https://bitbucket.org/fxt/beansoup/src/ab8ad814da3b285adfdffafe078c82fb68e9f827/beansoup/plugins/sort_docs.py?at=default&fileviewer=file-view-default

Add

plugin "beansoup.plugins.sort_docs"

to your beansoup file and you are all set.

[Martin Blais]

(1) 

I don't seen any problem with doing (1).

The sort order for Document directives vs. Transactions was left undefined because I didn't have a good reason to do otherwise.

You make a perfectly sufficient argument for baking this order into the source code.

I applied the change, ran the tests, and committing to it.

https://bitbucket.org/blais/beancount/commits/a832dc5dcb61596b1e60beacb9964a605b7898b3

(2) 

Bad idea. 

I've tried hard to avoid differing sort order, so that consistency across different users would match, so that debugging would be easier.

(3)

This is my second favorite option; this would work.

However, the one you suggest in (1) is also valid.

(4)

Evil!

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/7a861bde-d544-4b9e-a9ac-3daf5d074b9a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Filippo Tampieri]

Thank you!

--
You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/3ItOYS9DJx4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhOAJa%3DCB92Hsn83JjXw-HwBPFTuqPFnJu-WR%2BU8rstbUA%40mail.gmail.com.

[yegle]

Hi Martin,

Could you also explicitly specify the order of all non-transaction postings? As far as I can tell, the only one that explicitly state its ordering is the balance assertion (effectively 00:00 on the posting day).

Specifically, the order of pad/balance is not well defined, and if I need to have a pad right before a balance assertion, I have to do the pad on the previous day, and potentially a transaction could happen between the pad and the balance assertion.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAKgGm2iHq7u8ETQQUQ4tVFcY6_Dmn2P%3DVxaEkAk%3DBvpXy2txZQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Yuchen Ying
http://about.me/yegle

[Jacques Gagnon]

Yeah would be nice to be able to put pad and balance with same date.

Jacques Gagnon
GTalk/E-Mail: darth...@gmail.com
WLM (MSN): clou...@msn.com

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAFL5w3UhrAeybM%2ByJ-RfHY2qcLBd_P-LtY81He5UH0Wvy9--jw%40mail.gmail.com.

[Zhuoyun Wei]

Wow that's fast.

Previously my rendered credit cards journal looked like this (assuming statement date is 20th):

2016-03-19 "Shopping" -50.00 EUR

2016-03-19 "Shopping" -100.00 EUR

2016-03-20 document "/path/to/statement.pdf"

2016-03-20 "Shopping" -200.00 EUR

2016-03-20 "Shopping" -150.00 EUR

2016-03-21 balance -1000.00 EUR

There were transactions between "document" and "balance", which was weird. Now, "document" entries are at the end of the day, so much better now. Great!

But I am still a little bit confused at the timing of "balance" entries. They are defined to happen at the beginning of the day. But for merchants (say, a restaurant) in the real world, balance assertions usually occur at the end of day when they have stopped accepting new customers (no new transactions would happen on that day any more). For personal use, I do balance assertions for my Assets accounts on the last day of every month, it's a little bit weird to use the date 2016-04-01 when doing balance assertions on 2016-03-31 for transactions occurred in 2016-03. And for credit cards, it's weird that "balance" and "document" are not on the same date, since "balance" is determined on the same day when statement comes out.

I know the timing of "balance" entries were defined long long ago in design doc, and changing it abruptly would break almost everyone's ledger file, but I still hope there would be an "option" entry for users to choose, whether balance assertions should occur at the end of a day, or at the beginning of a day.

Or, a new syntax just popped up in my head when writing this mail:

2016-03-31 balance> Assets:Cash 100.00 EUR

2016-04-01 balance< Assets:Bank 200.00 EUR

Users could add suffix ">" or "<" to "balance" keyword, making balance assertions occur at the end or beginning of that date, respectively ("balance" keywords without suffixes still work).

Since a Beancount user would typically choose either "beginning-of-day-assertion-style" or "end-of-day-assertion-style", and not mix these two styles, a new "option" would suffice, introducing a new syntax may not be necessary anyway...

Just my two cents.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhOAJa%3DCB92Hsn83JjXw-HwBPFTuqPFnJu-WR%2BU8rstbUA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Zhuoyun Wei

[Martin Blais]

On Wed, Apr 6, 2016 at 12:13 AM, Zhuoyun Wei <wzyb...@gmail.com> wrote:

Wow that's fast.

Previously my rendered credit cards journal looked like this (assuming statement date is 20th):

2016-03-19 "Shopping" -50.00 EUR

2016-03-19 "Shopping" -100.00 EUR

2016-03-20 document "/path/to/statement.pdf"

2016-03-20 "Shopping" -200.00 EUR

2016-03-20 "Shopping" -150.00 EUR

2016-03-21 balance -1000.00 EUR

There were transactions between "document" and "balance", which was weird. Now, "document" entries are at the end of the day, so much better now. Great!

Glad it works!

 

 But I am still a little bit confused at the timing of "balance" entries. They are defined to happen at the beginning of the day. But for merchants (say, a restaurant) in the real world, balance assertions usually occur at the end of day when they have stopped accepting new customers (no new transactions would happen on that day any more). For personal use, I do balance assertions for my Assets accounts on the last day of every month, it's a little bit weird to use the date 2016-04-01 when doing balance assertions on 2016-03-31 for transactions occurred in 2016-03. And for credit cards, it's weird that "balance" and "document" are not on the same date, since "balance" is determined on the same day when statement comes out.

There are good arguments which exist for defining balance at either the beginning or the end. 

In general, intervals are usually best specified as [inclusive, exclusive[, and sometimes [inclusive, inclusive] is used.

I chose the latter, so that 2015-02-01 - 2015-03-01 can be understood clearly as "February", excluding 3/1.

Balance entries are defined w.r.t that.

The end-of-day balance used to be the default in Beancount 1.0 and I was always tripped up by it.

I also see how it would be nice to be able to have an end-of-day balance check, for the same reasons you do, but I rarely find myself needing it. 

I know the timing of "balance" entries were defined long long ago in design doc, and changing it abruptly would break almost everyone's ledger file, but I still hope there would be an "option" entry for users to choose, whether balance assertions should occur at the end of a day, or at the beginning of a day.

It would be trivial to implement the syntax for it, I would just add +1 day to the date and create a regular Balance entry for it.

In the journal, it would appear as day+1, however.

Is that good enough?

Or, a new syntax just popped up in my head when writing this mail:

2016-03-31 balance> Assets:Cash 100.00 EUR

2016-04-01 balance< Assets:Bank 200.00 EUR

Users could add suffix ">" or "<" to "balance" keyword, making balance assertions occur at the end or beginning of that date, respectively ("balance" keywords without suffixes still work).

I prefer to keep the directive names as identifiers for now, just letters.

Since the "end of day" balance is the odd one out, the current "balance" directives should remain named as such.

Perhaps this?

2016-03-31 balance_end Assets:Cash 100.00 EUR

2016-03-31 balance_eod Assets:Cash 100.00 EUR

2016-03-31 ebalance Assets:Cash 100.00 EUR

2016-03-31 eod_balance Assets:Cash 100.00 EUR

2016-03-31 end_balance Assets:Cash 100.00 EUR

2016-03-31 closing_balance Assets:Cash 100.00 EUR

2016-03-31 endance Assets:Cash 100.00 EUR

I don't really like any of those.

The least bad is the first IMO.

The last one aligns (same num of chars).

I wish for a better name. 

 

Since a Beancount user would typically choose either "beginning-of-day-assertion-style" or "end-of-day-assertion-style", and not mix these two styles, a new "option" would suffice, introducing a new syntax may not be necessary anyway...

Definitely not a good idea to have the same input infer different meanings, because then sharing bits of code on the list or in docs requires knowing how the option is set. I try to avoid this so far. I prefer to add a new keyword.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CALkVjQa%2B07qw__KMgOZi_-RvdXAhEKOFoL%3DytTHkay3TiNpitQ%40mail.gmail.com.

[Zhuoyun Wei]

On Wed, Apr 6, 2016 at 9:55 PM, Martin Blais <bl...@furius.ca> wrote:

2016-03-31 balance_end Assets:Cash 100.00 EUR

2016-03-31 balance_eod Assets:Cash 100.00 EUR

2016-03-31 ebalance Assets:Cash 100.00 EUR

2016-03-31 eod_balance Assets:Cash 100.00 EUR

2016-03-31 end_balance Assets:Cash 100.00 EUR

2016-03-31 closing_balance Assets:Cash 100.00 EUR

2016-03-31 endance Assets:Cash 100.00 EUR

I don't really like any of those.

The least bad is the first IMO.

The last one aligns (same num of chars).

I wish for a better name. 

I like "closing_balance" keyword the most. It sounds professional and has an opposite meaning to "opening balance" (which is asserted at the beginning of the day). English being my second language, I would like to hear opnions from other native English speakers... :-)

 

 

Since a Beancount user would typically choose either "beginning-of-day-assertion-style" or "end-of-day-assertion-style", and not mix these two styles, a new "option" would suffice, introducing a new syntax may not be necessary anyway...

Definitely not a good idea to have the same input infer different meanings, because then sharing bits of code on the list or in docs requires knowing how the option is set. I try to avoid this so far. I prefer to add a new keyword.

Hmm, that's what I had not considered about. You made a really good point. A new keyword would be a better solution than changing the behaviour of exsiting keywords.

Thanks Martin!

--

Zhuoyun Wei

[Martin Blais]

https://bitbucket.org/blais/beancount/issues/118/create-a-balance_end-directive

--

You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CALkVjQbGAgJiGFb0aT9rUUYtiWOYOWvJGUgKqgGsuSE7%3DrodCQ%40mail.gmail.com.

[Justus Pendleton]

On Monday, April 11, 2016 at 6:13:46 AM UTC+7, Martin Blais wrote:

https://bitbucket.org/blais/beancount/issues/118/create-a-balance_end-directive

To get my feet wet with parser changes, I took a stab at implementing this in https://bitbucket.org/blais/beancount/pull-requests/137/implement-balance_end-directive-for-issue

Like everyone else, I'm not thrilled with the 'balance_end' name, so if anyone has any better idea now's the time to share it :)

[Daniele Nicolodi]

Hello Justus,

I don't understand what issue this patch is solving. I have read the
mailing list thread, but I am still confused.

As implemented, the `balance_end` directive cannot be generated by the
import framework (as it does not have a python representation) nor it
can be manipulated with any of the beancount tools (as it is translated
to a plain `balance` directive).

It is thus only syntactic sugar that allows to write, for example,

2019-10-28 balance Assets:Foo 0.00 USD

as

2019-10-27 balance_end Assets:Foo 0.00 USD

which I find not that useful, once you know that `balance` applies at
the beginning of the day. I don't think that the advantages are worth
the increased cognitive burden in learning and interpreting the syntax.

If this is seen as something useful, I would advocate for adding an
extra argument to the `balance` directive, with a syntax like:

2019-10-27 balance ending Assets:Foo 0.00 USD
2019-10-28 balance beginning Assets:Foo 0.00 USD

or using `end` and `begin` instead, I don't know which one looks better
in this case (as a non-native English speaker I'm always confused).
Keeping `ending` to be the default, the current compact syntax would
still work. I thing the changes to the parser to support this syntax
would also be minimal.

Cheers,
Dan

[jus...@ryoohki.net]

On Tuesday, October 29, 2019 at 7:21:33 AM UTC+7, Daniele Nicolodi wrote:

I don't understand what issue this patch is solving. I have read the
mailing list thread, but I am still confused.

The patch simply implements an open request from a user that I found in the issue tracker.

 

2019-10-27 balance ending Assets:Foo  0.00 USD
2019-10-28 balance beginning Assets:Foo  0.00 USD

or using `end` and `begin` instead, I don't know which one looks better
in this case (as a non-native English speaker I'm always confused).
Keeping `ending` to be the default, the current compact syntax would
still work. I thing the changes to the parser to support this syntax
would also be minimal.

Sure, that also sounds like a plausible alternative solution. You should feel free to fork & submit a patch of your own. Given the general lack of feedback on my patch, it clearly isn't an issue anyone feels strongly about, though. Probably issue #118 should simply be closed as Won't Fix.