This is a known issue, see the settlement dates proposal, is being handled in the c++ rewrite, see v3 design doc. Also lots of history on the mailing list.
Currently you either fudge the dates or skip the occasional balance assertion that doesn't want to cooperate. It's unsatisfying but I've been living with it for ten years now Eventually the solution will allow you to provide both dates and the transaction will be split to two with a transfer account where the funds will transit through an account where the amounts in limbo sit. This could be handled by a simple plugin in you feel like it. Use metadata for the second date and split the transactions in the plugin. Should be core functionality though On Fri, Apr 2, 2021, 02:35 Tomasz Zurkowski <tomasz.zurkow...@gmail.com> wrote: > Hello everyone, > > I am still pretty new to beancount (I started my adventure around a month > ago) and I am still tuning my importers and my ledger. > > When writing importers for my banks, I realized that they often provide > multiple dates for one transaction, e.g. "booking date" and "purchase > date"), and I was wondering which I should choose as the date for the > transaction entry. Also, I was wondering if one of them is better, or > whether it is just a preference (e.g. if I would like to open source / > share the importers, should it be an option to choose one or the other, or > can I just choose one of them). > > Let me describe situation with UBS bank statement - they provide 3 dates: > "booking date", "trade date", "value date". Here is my current > understanding of them: > > - booking date - a day when bank puts a transaction into their books. > Most of the time (always?) it is greater or equal to the other two dates. I > also believe it has the nice property that once there is a transaction with > date X, then later imports (new transactions) will never have a date X or > before (which makes "balance" entries stable and never brake). > - trade/value date - I believe this is the date when the trade > actually occurred. For example if I bought something on Saturday, the day > will be Saturday but it can be booked on following Monday. The only > difference between trade and value date I found was when there is a > "e-bill" (a way in Switzerland to automatically pay bills). In this case > "trade date" will have a date when the transaction first shows in the bank > account "e.g. 2021-01-29", but then the value date is when the transaction > was scheduled for (e.g. first of the month, 2021-02-01). Booking date seems > to also match 2021-02-01 for those transactions (but I only have few of > those, so I am not sure if they will always match). There is one more > difference, when importing transaction, one can choose them to sort them > either by "booking date" or "trade date" - there is no way to sort them by > "value date" (import contains the "balance" column, that I could use to > generate automatic "balance" entry). > > Currently, I am using "value date" because it represents the actual date > of the trade (which helps me to remember what the transaction was for, if > the default bank transaction description is not clear), and it also > properly dates the periodic transactions that happen on e.g. first of the > month (makes sure there is always 1 transaction for rent in a given month). > > I am also consider using "booking date" (and saving "value date" somewhere > in the default description), so that I can automatically insert "balance" > entries, and those entries should almost never break with the new import. > > UBS credit card importer has very similar issue, the data contains two > dates: "booking date" and "purchase date" that have similar properties to > the above one. Small note I want to add here is a refund scenario. If I > purchased something on 2021-03-15, and then I return it, it is possible > that return will be processed much later (even 2 months later), so it could > be booked on "2021-05-15", but it would still have purchase date > "2021-03-15" (which means if I have any "balance" entries in my ledger, > they all break and I have to manually adjust them). > > Does anyone has similar issues? Any recommendations? Is it a personal > decision (some people prefer one or the other), or is there a better choice > (or something that should be at least considered a default / best > practice)? I would love to hear from others! > > Thanks, > Tomasz > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beancount/d2d384f1-8658-4268-9b66-ba5e63d13433n%40googlegroups.com > <https://groups.google.com/d/msgid/beancount/d2d384f1-8658-4268-9b66-ba5e63d13433n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhNj%3DWc0ASQfvXbGqgjFyhLEJzbU%3DUsjiAcyTcttS-8PMg%40mail.gmail.com.
