Thanks for the feedback! Responses inline: On Sunday, March 1, 2020 at 7:13:58 AM UTC-8, Justus Pendleton wrote: > > On Sunday, March 1, 2020 at 4:09:52 AM UTC+7, Red S wrote: >> >> I find being able to specify different dates for different legs (aka >> postings) of a transaction to be valuable. >> > > Very cool. I have (relatively) frequent need for this as well. There are, > unfortunately, all kinds of financial transfers that don't occur instantly. > In some cases I can live with the date on one leg being wrong but in others > I prefer more accuracy, especially when there are exchange rates or other > external factors involved. I've been manually doing this for years and will > be glad to switch over to a plugin to make it slightly more obvious what is > happening. >
Good use cases I hadn't thought of. I use my zerosum <https://github.com/redstreet/beancount_plugins_redstreet/tree/master/zerosum> plugin for some of those use cases, but depending upon one's preference to dedup their ingest, the effective_date plugin solves the same problem in a different way. > > A few quick comments based on scanning the plugin: > > For the LINK_FORMAT you might consider adding the date of the "real" > posting as part of it. e.g. something like edate-20191225-xkjm. I do that > in mine and find that having a tiny bit of human understandable context > often helps and prevents me needing to do more complicated > querying/digging. "Oh, it is probably that wire transfer, I think I did > that in late December". > I'd started out with exactly that format, but didn't like the length of the links. Instead, the plugin add the "original_date" metadata to the newly created transaction. In conjunction with the fact that the payee/narration remains the same, it provides enough human readable context for me. However, your feedback is now making me reconsider pushing the date into the LINK_FORMAT and removing original_date completely. That's simpler. > One thing I've struggled with is a nice way to do balance statements. You > want some assurance that no money got left behind in limbo in some fake > account I never look at. Of course, that's a bigger problem when it is all > done manually. But it is hard to autogenerate balance statements when there > could be multiple transactions in-flight using the holding account. e.g. > you can't just make a balance statement after the final edate to assert $0. > How do you handle balance statements for this Hold account in your own > usage? > I personally don't find that to be a problem with effective_date, because the holding account is used solely by the plugin and is always eventually zero barring bugs. So the only use I'd see is to uncover bugs in the plugin-code. Are you seeing other use cases? However, I do run exactly into the problem you mention when using the zerosum <https://github.com/redstreet/beancount_plugins_redstreet/tree/master/zerosum>plugin. There, a non-zero value may indicate incorrect ingest or worse, a banking error. To catch these, I have my zerosum accounts tree auto-expanded visually (see this patch <https://github.com/beancount/fava/pull/930> in fava) whenever it is non-zero. -- 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/c011f809-3576-49cc-b5ef-581fa3472d03%40googlegroups.com.
