Questions about ledger to beancount

[Martin Michlmayr]

I have a few question about moving from ledger to beancount:

1) Ledger has a "D" directive (e.g. D 1000.00 EUR). It sets the
default currency (operating_currency in beancount) but it also
sets the format (so if I use D as above and then write 10 it would be
printed as 10.00). I don't think there's an equivalent for
beancount, right?

2) "N" says that pricing information for that commodity should be
ignored (and no price quotes are downloaded). It's basically your
"home currency" (operating_currency). I don't think there's
an equivalent, right?

3) C AMOUNT1 = AMOUNT2: Specifies a commodity conversion, e.g. "C 1.00
Kb = 1024 bytes". Is that somehow possible in beancount?

4) Can you "define" variables and then use them in transactions?
e.g.
define foo=$100
Expenses:Purchase $foo

5) Has anyone done plugins for ledger's automated transactions and
periodic postings?

6) Has anyone done a table comparing ledger and beancount syntax, and
if not, would that be of interest?

--
Martin Michlmayr
http://www.cyrius.com/

[Patrick Ruckstuhl]

5) I created a simple importer which takes care of this for me. It runs and creates real entries based on the schedule.

[Martin Blais]

On Thu, Mar 29, 2018 at 11:02 AM, Martin Michlmayr <t...@cyrius.com> wrote:

I have a few question about moving from ledger to beancount:

1) Ledger has a "D" directive (e.g. D 1000.00 EUR).  It sets the
default currency (operating_currency in beancount) but it also
sets the format (so if I use D as above and then write 10 it would be
printed as 10.00).  I don't think there's an equivalent for
beancount, right?

Not specifically, though I want to implement a new option to override the inferred precisions explicitly, that would achieve the same thing.

Right now you can set the default tolerance when it cannot be inferred from the input numbers; that's not enough.

The precision is also inferred from the numbers parsed in the input (see DisplayContext in the code).

Note that precision != tolerance. Precision is what numbers get rendered to. Tolerance determines the amount of imprecision (residual) accepted silently in balancing. But these things are related conceptually.

I think that most users would just choose to set their favorite precision to render.

Also, it'll have separate options for the precision of units and for cost/prices, which often demand more digits.

(One good thing about this state of affairs is that the harder work of automatically inferring decent tolerances from inputs is already done, so setting these won't be strictly necessary, but I'll admit it's an ass-backwards design, setting the precisions explicitly and just using them is way easier and could have been a good starting point. I was trying to minimize the amount of options.)

2) "N" says that pricing information for that commodity should be
ignored (and no price quotes are downloaded).  It's basically your
"home currency" (operating_currency).  I don't think there's
an equivalent, right?

Beancount does not itself download anything., so this does not apply.

The input is assumed all contained in the file (that's on purpose, intended to be deterministic).

I think the closest equivalent is the operating currencies option, which affects only reporting (and not calculations).

3) C AMOUNT1 = AMOUNT2: Specifies a commodity conversion, e.g. "C 1.00
Kb = 1024 bytes".  Is that somehow possible in beancount?

No.

4) Can you "define" variables and then use them in transactions?
e.g.
define foo=$100
    Expenses:Purchase             $foo

Neither.

I specifically kept Beancount's language a little lower level on purpose; the idea was to define a small core of features and let the user generate some of this data programmatically via plugins.

I'm not sure how useful those definitions would be; I've never needed them. Most of the data I input comes from imported transactions. I have never need to define things in that way, values are just imported and never change. That seems only useful for "theoretical" purpose. You would never want to put a recurring value and not check every payment--the vast majority of real payments involve some exceptions now and then. I'd be curious to hear about use realistic cases.

Note that you could achieve this via preprocessing, e.g., m4?

5) Has anyone done plugins for ledger's automated transactions and
periodic postings?

Not AFAIK.

There's an example plugin, but it's intended more as an example than anything else.

6) Has anyone done a table comparing ledger and beancount syntax, and
if not, would that be of interest?

I'm not aware of anything like that.

--
Martin Michlmayr
http://www.cyrius.com/

--
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+unsubscribe@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/20180329150207.e5tu6yxrklrvf5sr%40jirafa.cyrius.com.
For more options, visit https://groups.google.com/d/optout.

[Simon Michael]

On 3/29/18 4:02 PM, Martin Michlmayr wrote:
> 6) Has anyone done a table comparing ledger and beancount syntax, and
> if not, would that be of interest?

Hi Martin,

I'd be interested in anything you come up with. I made
http://plaintextaccounting.org/quickref a while back. Since then I
thought it would be more maintainable to have a standard examples doc
repeated for each ledger-like, optionally combined back into tabular
format by a script. The quickref-X.md files at
https://github.com/plaintextaccounting/plaintextaccounting.github.io/tree/master/quickref
were a start at this.

Best