Reminders
Hello. It would seem that reminders that are one-time entries, should automatically remove themselves from the reminder list (on the reminder page) once the entry has been recorded. This should happen automatically for reminders that are:
1. non-recurring and manually entered
2. recurring but have exceeded their end date and/or number of entries
S for example, I make a one time reminder to pay my phone bill on the 15th, and choose to manually enter it on the 12th. I do this from the reminder list on the main screen, by recording it into my reguster. yet, the same reminder REMAINS on the reminder list (on the reminder page) until I remove it manually. This makes absolutely no sense.
I regularly have to cull old reminders from my list well after they have been used, and if I have created new ones for the same payee, must check each one to see which are new and which can be removed.
It would seem to me that this would be basic mode of operation of any reminder function.
So: am I missing something (a preference that enables this for example) or am I the only one?
Thanks
Alan
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Henry on 05 Sep, 2018 12:13 PM
Hi Alan,
Thank you for contacting us.
I am afraid there is no automatic option to remove old reminders from the reminder list. You have to delete them manually as you did before.
I have attached the relevant suggestion ticket to this thread so our developers can consider this feature.
Henry
Infinite Kind Support
2 Posted by amarc on 05 Sep, 2018 01:31 PM
Henry: Thank you for forwarding the note. Hard for me to understand how
this notion was not simply a part of the original routine. Once a
reminder does it's assigned job, then why would it continue to hang
around? If you hired someone to do a job around your house, say fix your
garage door, once he is done, do you want him just hanging around
forever? I think not.
I spent many years writing software, and while I like Moneydance very
much, especially for it's simplicity, it seems like the developers have
not carried some functions to their obvious conclusion. I don't know if
this is due to budgeting constraints, short staff, or lack of
imagination, but IMHO, this is certainly a good example. I can't imagine
why you would need a "suggestion" to finish the reminder's job! Which is
simply to remind you "X" number of times, then go away.
All the components are in place, and one simple routine, probably a
single line of code, would finish the job.
Is my job done? If no, then continue to live. If yes, then die.
Thanks for the consideration.
Alan
3 Posted by iandarkwater on 05 Sep, 2018 06:25 PM
I can easily see the argument to leave things as they are!
I have insurances that continue from year to year but pay as 10 monthly payments. Hence they finish before restarting again at the start of the next year.
It's convenient that the reminder is not auto-deleted then I can set it off again.
I know that I could set up a new reminder from an old payment but I think that I'm happier with reminders not auto-deleting.
MD could have a flag to allow auto-delete or not.
4 Posted by amarc on 05 Sep, 2018 08:08 PM
< I can easily see the argument to leave things as they are!>
A one sided argument to be sure.
Of course you would, as a matter of best practices, make the option
available to auto delete or not. But things as they are are only good
for those served by a particular point of view, which is always only a
portion of the user base for any software.
There are so many ways you could do this, but at the end of the day, if
you are using a one off, you want it to disappear, or at least have the
option to have it disappear. That is the life of a one off item.
Software lives to manage these types of tasks, and having a garbage heap
of dead reminders serves no purpose.
It becomes a matter of best practice, and in my opinion, the function as
it stands now is simply incomplete.
Ian Douglas wrote:
5 Posted by dwg on 05 Sep, 2018 09:47 PM
It is really a matter of User requirements.
You each have a different requirement, one wants a single use reminder that automatically deletes, the other wants a reusable reminder. Neither are invalid uses and both if at all possible should be accommodated.
To my mind the solution to push for is a check box to automatically delete the reminder after the last use. This way the function can serve both usages models
6 Posted by amarc on 05 Sep, 2018 09:59 PM
Exactly correct. Neither one is right, or wrong. But both make for a
more flexible system.
My point simply being that it would have been the logical conclusion to
the Reminder function and should have, again...in my opinion...should
have been written when the reminders were created. Else, the function is
incomplete.
From a coding standpoint, not to mention best practice, it is always
easier and less of a risk to complete a given function before it is
integrated into the bigger picture. One hates to go back and finish
something after the fact.
Which is a good reason why it may never happen.
Regardless, like to use MD and it has many attractive things that make
it what it is.
dwg wrote:
7 Posted by dwg on 05 Sep, 2018 10:58 PM
I feel that Tik suffers from the problems that many small organisations face.
In a large software house you have reams of Product requirement documents including detail function requirement documentation. The result of many many hours of research of the market requirements, competitor products etc.
I would not expect that TiK has the resources in terms of either people or money do do such work, hence the product more evolves over time. The syncing capability reminds me of this as you have the basic capability, but you do not really have the capability needed for ongoing maintenance of the solution in terms of how to manage the incremental files nor methods to seamlessly force a full resync if it is required, thus leaving the user to manually stop the process and setting it up from scratch,'
in short it is not ideal but I understand why and how it happens in the real world, Alas I do not see any simple, not to mention cheap, effective solutions.
8 Posted by amarc on 06 Sep, 2018 12:06 AM
I'm sure you hit the nail squarely on the noggin. The sync issue is
interesting as well. I have no need to use it, but explored it when I
first began to use the program, and just didn't feel it was mature
enough. But I am just a single user, so it matters little if at all to me.
Often times with small organizations, sometimes just a few people in
fact, there is a brain that creates the initial product, then leaves or
is replaced and now you have a diversion in the natural evolution of the
product. A different point of view, skill set or personal preference
sends the code into a slightly different orbit resulting in odd
combinations of functions and features.
For me, the tip off was the lack of feedback during the backup process.
No report or gauge of progress, just a notice of the process ending. Odd
to me, as feedback is everywhere. But these are most likely routines
that must be home grown, and can be set to a back burner or eliminated
from the flow chart altogether as other pressing items present themselves.
Regardless, the suggestion has been made. It obviously isn't a deal
breaker as there are other more pressing issues to be sure. My big pet
peeve is the merge function. How can you allow a new debit item to be
merged with an old item that has already been cleared? That is truly a
huge issue. But if you don't set your time frame tight enough, that will
happen, and can you imagine the havoc that would cause in a situation
where there are thousands of transactions a month?
Allowing this function to settle on only a time frame to judge whether a
previous transaction may be merged into a new one is downright crazy.
And very poor judgement. But from experience, it smacks of taking the
easy way out. But again, an unfinished function. Because disallowing a
transaction to be merged into a new one should depend FIRST on whether
it has already been cleared. If it has, how do you offer it up for merger?
Until I figured this out, it wrecked my register several times. I had no
idea I was losing transactions because they were being merged into ones
that were already cleared!
Regardless, I gave up Quicken because I found MD to be suitable for my
needs, without all the muss and fuss that I don't want or need. i
actually enjoy using MD and look forward to it maturing as we go forward.
For me, less is more, and MD fits nicely in that equation.
Kind regards....
dwg wrote:
9 Posted by dwg on 06 Sep, 2018 01:14 AM
I do not see that a transaction being marked as cleared should exclude it being merged with a downloaded transactions. You could easily enter a transaction by hand mark it as cleared and then decide to download transactions. If you are doing this via an OFX download and you do not allow it to be merged you are not allowing the transaction ID to be added to the transaction and thus facilitate the automatic discarding of duplicates..
System closed this discussion on 06 Dec, 2018 01:20 AM.