FIFO validation with STRICT booking

[sm...@davethehappysinger.com]

Hi folks,

I use a FIFO methodology for capital gains but with STRICT booking, inputting the lots I sell explicitly (relying heavily on vim-beancount's GetContext, but increasingly also automating this with importers that accept the prior entries).

I have two reasons: I'm affected by the "transfer lots with cost" issue discussed at length in crypto contexts, but a crypto transfer with a fee means increasing the cost base slightly while preserving the date. All things considered, this is safer to do explicitly so I can see what's going on. I also find it personally preferable for everything to be explicitly expressed in the text. It's aesthetically appealing and reassuring to me that I haven't misunderstood beancount if it's done explicitly.

Which brings me to my question: I have in mind a plugin that would check the transactions after all the parsing and processing is complete, and assert that the lots I've explicitly reduced are the ones that are consistent with a FIFO approach.

I think this is something useful and that I could reasonably write (and open-source) when I have time, but I wanted to ask if anyone's aware of an existing plugin that does this?

A further thought is that if I choose `option "booking_method" "FIFO"`, then it would be extremely cool if beancount would not just interpolate missing bookings according to FIFO but also consider it an error if I have explicitly booked a reduction that doesn't conform to FIFO. I'll leave it up to Martin to decide whether this validation is in the scope of `booking_method` or whether this belongs to a plugin.

Thanks for reading!

[Martin Blais]

Sure why not.

But you could also write your own booking method that does just this instead?

I would call it "CHECK_FIFO".

(Problem is it's orthogonal to all the methods, e.g. CHECK_LIFO, etc.. Whatever.)

Right now I don't have a registration mechanism so you'd have to either 

- patch the code

- monkey-patch the code without change the library (not sure if possible)

- send me a patch to add a registry so you can do this cleanly

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/beancount/2a2682b6-83d9-4288-a3d5-c7c5b2659cafn%40googlegroups.com.

[sm...@davethehappysinger.com]

Thanks for the reply, Martin!

In the absence of anyone piping up to say such a plugin already exists that I've overlooked, I might implement this as a plugin first to share with you all, and then consider contributing to a "custom booking method" registry feature if there's interest in it. But it will be a little while before I can contribute either in any case.

[Ben Blount]

Custom booking methods would be fantastic.

Does anyone have thoughts on how such a registry would be configured?

The only mechanism that comes to mind as workable would be to register it like plugins are currently. Given the plans to add pre-booking plugins in v3 that work on direct-from-parser inputs, I imagine those would take a similar approach.

So maybe we'd have 2 additional plugin directives:

pre_plugin <python_path>

booking_plugin <python_path>

which matches today's  plugin <python_path>

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/37a15b36-1b13-4166-9402-2a81f4c56249n%40googlegroups.com.

[Martin Blais]

Extra directives look ugly to me. Trying to keep the language lean.

I'd just have a Python-level feature and you'd have to write your own main with load_file().

It's pretty exotic anyway.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CACGEkZtm9-OuYNxk8ccseyqPYrwT-nGPMdNyZiovLN%2Bp2kGRGA%40mail.gmail.com.

[Ben Blount]

That rules out using any of the CLIs that trampoline to Python unless they all get hooks too.

What about keeping that single plugin directive but allow the plugin code to implement different interfaces depending on what plugin type it is?

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhPTCp_%3D%2BSCfVEqZdHDcTqhLNhdPn2pyMRPgu9Owda%2BxCQ%40mail.gmail.com.

[sm...@davethehappysinger.com]

I'll confess I haven't looked at the plugin architecture in detail (beyond the docs, basically), but it seems to me that if a plugin is enabled by the beancount directive, there are a couple of ways it could hook in in more places:

- a plugin class or module couple implement "well known" function/method names that are called in sequence at specific points in the processing flow (as is done for importers with the extract/identify methods)

- a plugin module could register its own arbitrary callables to hooks with something like "beancount.plugins.register_callback("post_booking", myplugin.check_fifo)

I think the existing plugin architecture is fine for my purpose (raising an error if the final processed directives are inconsistent with FIFO). But adding a new named booking method could, in a generic framework of many hooks as described above, just be a matter of providing hooks in the right places for beancount to call out to plugins.

[Martin Blais]

This all sounds complicated to me.

I'd prefer to just expose a hook (a-la-Emacs) and you can call it when your plugin module gets loaded.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/54b8e336-00aa-47f9-acdd-44b2f8162500n%40googlegroups.com.