How do I edit all details of one instance, of a recurring bill? (Q Mac)

Due to the recent storms, California has extended the payment deadlines for federal and state income taxes - as well as the 4th estimated tax payment for last year, and the 1st estimated payment for this year - to May 15th (see https://www.irs.gov/newsroom/irs-california-storm-victims-qualify-for-tax-relief-april-18-deadline-other-dates-extended-to-may-15

I have recurrences in my Quicken schedule for each of these entries (quarterly estimated + actual tax payments, for both Federal and State), and would like to update the applicable instances to reflect the new dates - as well as provide myself a comment as to why these are off-cycle (to help with future reviews/reports). But, I do not want to change the schedule of this entire recurrence itself - since after these next few months, the schedule will revert to the standard one.

Unfortunately, while I can update the date or the amount for one particular instance, I cannot update the tags or notes associated with that instance. Why not? I don't wish to "Mark as Paid" (it has NOT yet been paid; I need to keep it as a reminder), I don't wish to "Skip this instance" (it still NEEDS to be paid), and I don't wish to "Edit All Instances" - I just want to make updates to additional fields for this particular entry.

Does Quicken really not allow for such a situation? Do I have to find some odd workaround (e.g. skip this instance, but then manually create a new one-time scheduled entry for each of these), just to be able to add notes to the next instances?

Answers

  • Jon
    Jon SuperUser, Mac Beta Beta
    I think the only way to handle that would be to change the existing scheduled payment so it skips over the next two payments, so the next payment is the one that's back on the normal schedule. Then create new scheduled payments for the ones that are delayed.

    Quicken Mac subscription. Quicken user since 1990.

  • CyborgOne
    CyborgOne Member ✭✭✭
    Yep, that's what I was afraid of - thanks for the response, @Jon. Certainly a logical, and fairly easy, workaround - but frustrating, nonetheless. 

    If Quicken already provides for editing a single (next) instance, why not allow for editing ALL fields of that instance?  A possible enhancement request, to be logged?
  • RickO
    RickO SuperUser, Mac Beta Beta
    CyborgOne said:
      A possible enhancement request, to be logged?
    This might be what you're looking for: Re: In Q Mac, Edit Transaction Instance for ANY Future Transaction Like Windows Versions
    Quicken Mac Subscription; Quicken Mac user since the early 90s
  • gregneg
    gregneg Mac Beta Beta
    edited January 2023
    You could just go online with the Feds and California and tell them to come and get your money. You set the amounts and times.  
       You get to keep your Quicken cash flow coordination records --- without using them as a check-writing reminder.

    Feds:   https://www.eftps.com/eftps/

    California:    https://www.ftb.ca.gov/myftb/index.asp


      I'll definitely agree that we need to be able to edit more in those scheduled payments --- like Memo/Notes/ Attachments.

    27" iMac 5K OS Ventura Quicken user since it was just a check register.

  • jacobs
    jacobs SuperUser, Mac Beta Beta
    CyborgOne said:
    If Quicken already provides for editing a single (next) instance, why not allow for editing ALL fields of that instance?  A possible enhancement request, to be logged?
    Because the future transactions don't actually exist in the database. A scheduled transaction is a template for creating future transactions; as such, it cannot accommodate each future transaction being different. Of course, they could re-design the way scheduled transactions work, but it would be a significant architectural change the program.
    Quicken Mac Subscription • Quicken user since 1993
  • CyborgOne
    CyborgOne Member ✭✭✭
    Understood - but if the next instance is already a "special case" (we can modify it, outside of the recurrence itself), why not allow access to modifying all fields of that one instance?

    …but the structure of how such escapes are handled on the back end, seems it may remain a challenge (modification of specific date instances, vs. modification of specific field for a given instance) 
  • jacobs
    jacobs SuperUser, Mac Beta Beta
    CyborgOne said:
    Understood - but if the next instance is already a "special case" (we can modify it, outside of the recurrence itself), why not allow access to modifying all fields of that one instance?
    I recall this came up several years back, and the former Quicken Mac product manager explained why it couldn't be done at that time. I'm guessing the reason remains the same today. I found his post from August 2019, when the question was asked about why the Memo field of the next instance couldn't be edited:
    Quicken Marcus said:
    The unsatisfactory answer to why we don't allow you to edit the memo field is because Quicken Windows doesn't support it and the Quicken Cloud's feature set for scheduled transactions is defined by Quicken Windows.  We aren't syncing scheduled transactions [in the then-current version 5.12] but the feature is defined by the Quicken Cloud feature set.  I can see there is some value in being able to edit more than the date and amount and I personally think we should allow one to edit future instances in addition to the next instance — but we don't allow that today. If you want to edit those fields you can still mark the transaction as paid and edit them.  Of course, the downside is they become real transactions and one may not want them to become real because it changes their workflow.  This doesn't mean we won't allow editing of memo and other fields in the future but it's not there today.

    Quicken Mac Subscription • Quicken user since 1993
  • CyborgOne
    CyborgOne Member ✭✭✭
    Heh - what they indicate as a workaround (just enter the that instance, and modify it from there) is exactly what I've been doing, and obviously works well enough.

    And, while the info you provided is perhaps not an optimal justification as to the reason for this limitation … I certainly am very glad to have the details.

    Thanks, as always, @jacobs !
This discussion has been closed.