Updated <https://github.com/redstreet/beancount_plugins_redstreet/commit/cdb2d42e74362e47d01cc94128134d696b17e6f7>. I kept the original_date metadata which is useful in queries. I contracted the link (6dig date + 3char rand_string). Thanks for the suggestion!
On Sunday, March 1, 2020 at 3:57:23 PM UTC-8, Red S wrote: > > 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/fbd56593-c09e-4005-976d-b739fa2473b7%40googlegroups.com.
