There are many workflows that are valid in different contexts. Beancount
gives you tools that can be adapted to the different workflows.
This is one reason why the importers "framework" has been split out from
the core project. It's value is mostly in providing a common interface
so that importers that translate different input formats into Beancount
data structures can be shared.
On 18/07/23 04:24, Eric Altendorf wrote:
This kind of workflow makes me uncomfortable in general; mixing manual
effort with automation (e.g., importers) means that you can only
automate the first time (this is why one never edits generated code).
But, coordinating manual effort with automation is a very hard problem
to solve cleanly in general and I can see how this works well enough for
a lot of use cases.
There are two modalities in which you can operate, distinguished by what
you define to be the "source of truth":
1. you have the source of truth to be the input files for your
importers, and that the importers are "smart" enough to generate a
Beancont ledger with all the information you need for further
processing. In this case, you don't need to worry about mixing manual
and automated steps: you can regenerate your ledger from the input files
at any time.
2. you can have the Beancount ledger to be the source of truth, and the
importers are meant to produce a ledger that you manually edit. For this
use case, the importers framework have support for this use case via the
deduplication system: it uses some fuzzy matching between transactions
to identify transactions in the imported batch that are already in your
ledger.
What you seem to be after is a way to update the ledger entries with new
infomartion (either by running an improved version of the importers or
by combining information from different sources). This is possible, but
Beancount does not offer any facility for this. The main reason is that
the logic for merging or updating the ledger entries the core of the
problem and it cannot be generalized. However, the "boring" code around
the problem is readily available: you can easily parse a Beancount
ledger, modify it, and serialize it back into an human readable ledger,
see the beancount.parser.parser and beancount.paerser.printer modules.
The only drawback in doing so is that the Beancount parser does nor
preserve whitespace and comments, thus you loose these when you go
through this process. The autobean.refactor project should solve the
issue, but I haven't had occasion to try it yet.
Also ... it's not even clear to me that Beancount would guarantee the
same outputs given the same inputs -- e.g., if you use FIFO booking,
there could be many buy transactions on the same day at different
prices, and I don't know if Beancount would guarantee a stable ordering
among those. Seems like it could be implementation dependent...
It is guaranteed to be stable.
I can snapshot the beancount inputs, and I can snapshot the beancount
outputs, but what I am trying to understand is if there's a way to turn
the beancount outputs (its choice of lot matching) around and use them
as inputs (specified lot matches) next year.
I don't understand what you are asking. The automated lot matching is
not stored anywhere thus you cannot "reuse" it when you change the tot
algorithm. However, the automated lot matching algorithm is only a
convenience: you don't need to use it and always specify lots manually.
Specifying the lots explicitly is the easiest solution if you want some
"non-standard" lot matching or you want the lot matching to change over
time. More complex solutions may involve plugins to augment the
transaction read from your ledger with lot information computed with
some arbitrary algorithm.
Cheers,
Dan
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beancount/96ffd7de-d3ce-4a95-4457-cd6ecf45449b%40grinta.net.
