Colin Scott
My feedback
4 results found
-
40 votesColin Scott
supported this idea
·
-
23 votes
An error occurred while saving the comment -
5 votes
An error occurred while saving the comment Colin Scott
commented
I am Treasurer of my Rotary Club. I provide a monthly report so each of our service committees knows how much they have "in the bank". This report uses "today" as its date, so I simply print it and it works.
Some spending decisions are made in advance, and so we have forward-dated transactions - sometimes 2 or 3 years ahead! - in the accounts. Each committee therefore needs to know not only its current balance, but their future commitments, and for this I produce a transactions report of all forward-dated transactions. Initially I had this set up as from today to (I think!) 01-Jan-2025, and it ran automatically - but then I realised that it showed today's transactions, which is wrong because they are already reflected in today's balance. To fix it at present I need to manually enter tomorrow's date whenever I run the report, which is a slight pain!
An increment/decrement facility would suit me fine for this, and the flexibility it offers is potentially quite useful, though I can't offhand think of any specific instances. It might be a way in which you could get rid of one or two symbolic dates, though! :-)
Colin Scott
shared this idea
·
-
provide per-transaction cancel of autofill, with ESC, initial backspace, or anything else that works
65 votesColin Scott
supported this idea
·
An error occurred while saving the comment Colin Scott
commented
There are two separate aspects to the autofill problem - the annoyance with entering text, and the annoyance with reproducing all the splits from an earlier transaction. Sometimes you want the auto-text, but not the auto-splits! So we need two separate solutions. Note that getting rid of the auto-splits should ideally remove *all* splits, unlike the current "delete transaction splits" approach, which leaves one split complete with a split amount. At the very least the split amount should be zeroed ...
This is a sensible idea, but is only part of a rather wider picture relating to whether data (and preferences) should be global or local. For example, if you are running multiple books then you will almost certainly also want to have a different set of custom reports for each book. Ideally one should have the option, for any individual report, for it to be either global or local to the current book - presumably this should be an option on "save as" (if that ever gets implemented!).