Hi, On Tue, April 7, 2020 10:21 am, Dale Phurrough via gnucash-devel wrote:
> 1. > This time period of one month is arbitrary and my experience suggests this > is a symptom of a hack, incomplete solution, or partial workaround. Both > (a) allowing future/advance reconciliation -and- (b) disallowing something > "too far ahead" is again arbitrary and is forcing an arbitrary accounting > policy rather than conservative double-book rules and math. > Features with rules which are defined by the computer clock > are troublesome. It makes sense when one needs to transfer money via an > online API. It doesn't make sense when one is doing core accounting tasks. > Also this seems (in my shallow understanding of the 3.9 change) to not > work > with that 3.9 change. How could someone future reconcile if future-date > splits wouldn't be valid with respect to the future-target-reconcile > balance? This suggests a cascade of more workarounds. I will comment on this, because this came directly from a conversation that Chris and I had. Chris originally wanted to ensure that reconciles could never happen in the future *at all*. I.e., it would not allow you to future-reconcile. I said that I do often future-reconcile. My use-case is that I keep track of my reimbursable expenses using cleared/reconciled flags to denote that I expensed them (cleared), and the expense was reimburned (reconciled). So when I file my expense report I mark those items as cleared. Then when the reimbursement check comes in, I reconcile down to $0. My issue is that I want to do this (enter the reimbursement check and reconcile) on the day I receive the check, however the check only gets deposited the next day, so I need to be able to reconcile 1-2 days into the future. When I proposed this use-case to Chris, he suggested a month leeway, and I didn't push back saying "that is too much." If you have an ACTUAL use-case of future-reconciling I would like to hear it, because this is the only future-reconcile use case I have come across. Everything else in my experience is reconciling in the past. > 2. > I highly discourage altering any data without explicit disclosure and > acceptance of each change occurrence. This is not in alignment with the > ideas of data integrity, data persistence, trust and disclosure, etc. > Also a similar arbitrary accounting policy with the suggested date>1month > logic and 1/1/1970. GnuCash already has several places where is will correct (read: alter) data entries on the fly, when it Scrubs the accounts. It does this with bad strings and invalid dates, among other corrections. It will already do these corrections silently when the data file is loaded. Having said that, it probably still makes sense to pop up a dialog to warn the user if it finds this kind of "invalid" data. > --Dale -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel