Skip to content

Colin Scott

My feedback

4 results found

  1. 40 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Colin Scott supported this idea  · 
  2. 23 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Colin Scott commented  · 

    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!).

  3. 5 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    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  · 
  4. 65 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Colin 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 ...

Feedback and Knowledge Base