tag:infinitekind.tenderapp.com,2009-01-14:/discussions/suggestions/12126-remindersInfinite Kind: Discussion 2019-04-15T19:28:28Ztag:infinitekind.tenderapp.com,2009-01-14:Comment/460124402018-09-05T12:13:24Z2018-09-05T12:13:24ZReminders<div><p>Hi Alan,</p>
<p>Thank you for contacting us.<br>
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.<br>
I have attached the relevant suggestion ticket to this thread so our developers can consider this feature.</p>
<p>Henry<br>
Infinite Kind Support</p></div>Henrytag:infinitekind.tenderapp.com,2009-01-14:Comment/460124402018-09-05T13:31:13Z2018-09-05T13:31:13ZReminders<div><p>Henry: Thank you for forwarding the note. Hard for me to understand how<br>
this notion was not simply a part of the original routine. Once a<br>
reminder does it's assigned job, then why would it continue to hang<br>
around? If you hired someone to do a job around your house, say fix your<br>
garage door, once he is done, do you want him just hanging around<br>
forever? I think not.</p>
<p>I spent many years writing software, and while I like Moneydance very<br>
much, especially for it's simplicity, it seems like the developers have<br>
not carried some functions to their obvious conclusion. I don't know if<br>
this is due to budgeting constraints, short staff, or lack of<br>
imagination, but IMHO, this is certainly a good example. I can't imagine<br>
why you would need a "suggestion" to finish the reminder's job! Which is<br>
simply to remind you "X" number of times, then go away.</p>
<p>All the components are in place, and one simple routine, probably a<br>
single line of code, would finish the job.</p>
<p>Is my job done? If no, then continue to live. If yes, then die.</p>
<p>Thanks for the consideration.</p>
<p>Alan</p></div>amarctag:infinitekind.tenderapp.com,2009-01-14:Comment/460124402018-09-05T18:25:53Z2018-09-17T09:02:49ZReminders<div><p>I can easily see the argument to leave things as they are!<br>
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.<br>
It's convenient that the reminder is not auto-deleted then I can set it off again.<br>
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.<br>
MD could have a flag to allow auto-delete or not.</p></div>iandarkwatertag:infinitekind.tenderapp.com,2009-01-14:Comment/460124402018-09-05T20:08:29Z2018-09-05T20:08:29ZReminders<div><p>< I can easily see the argument to leave things as they are!></p>
<p>A one sided argument to be sure.</p>
<p>Of course you would, as a matter of best practices, make the option<br>
available to auto delete or not. But things as they are are only good<br>
for those served by a particular point of view, which is always only a<br>
portion of the user base for any software.</p>
<p>There are so many ways you could do this, but at the end of the day, if<br>
you are using a one off, you want it to disappear, or at least have the<br>
option to have it disappear. That is the life of a one off item.<br>
Software lives to manage these types of tasks, and having a garbage heap<br>
of dead reminders serves no purpose.</p>
<p>It becomes a matter of best practice, and in my opinion, the function as<br>
it stands now is simply incomplete.</p>
<p>Ian Douglas wrote:</p></div>amarctag:infinitekind.tenderapp.com,2009-01-14:Comment/460124402018-09-05T21:47:20Z2018-09-05T21:47:20ZReminders<div><p>It is really a matter of User requirements.</p>
<p>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.</p>
<p>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</p></div>dwgtag:infinitekind.tenderapp.com,2009-01-14:Comment/460124402018-09-05T21:59:04Z2018-09-05T21:59:04ZReminders<div><p>Exactly correct. Neither one is right, or wrong. But both make for a<br>
more flexible system.</p>
<p>My point simply being that it would have been the logical conclusion to<br>
the Reminder function and should have, again...in my opinion...should<br>
have been written when the reminders were created. Else, the function is<br>
incomplete.</p>
<p>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<br>
integrated into the bigger picture. One hates to go back and finish<br>
something after the fact.</p>
<p>Which is a good reason why it may never happen.</p>
<p>Regardless, like to use MD and it has many attractive things that make<br>
it what it is.</p>
<p>dwg wrote:</p></div>amarctag:infinitekind.tenderapp.com,2009-01-14:Comment/460124402018-09-05T22:58:00Z2018-09-05T22:58:00ZReminders<div><p>I feel that Tik suffers from the problems that many small organisations face.</p>
<p>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.</p>
<p>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,'</p>
<p>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.</p></div>dwgtag:infinitekind.tenderapp.com,2009-01-14:Comment/460124402018-09-06T00:06:26Z2018-09-06T00:06:26ZReminders<div><p>I'm sure you hit the nail squarely on the noggin. The sync issue is<br>
interesting as well. I have no need to use it, but explored it when I<br>
first began to use the program, and just didn't feel it was mature<br>
enough. But I am just a single user, so it matters little if at all to me.</p>
<p>Often times with small organizations, sometimes just a few people in<br>
fact, there is a brain that creates the initial product, then leaves or<br>
is replaced and now you have a diversion in the natural evolution of the<br>
product. A different point of view, skill set or personal preference<br>
sends the code into a slightly different orbit resulting in odd<br>
combinations of functions and features.</p>
<p>For me, the tip off was the lack of feedback during the backup process.<br>
No report or gauge of progress, just a notice of the process ending. Odd<br>
to me, as feedback is everywhere. But these are most likely routines<br>
that must be home grown, and can be set to a back burner or eliminated<br>
from the flow chart altogether as other pressing items present themselves.</p>
<p>Regardless, the suggestion has been made. It obviously isn't a deal<br>
breaker as there are other more pressing issues to be sure. My big pet<br>
peeve is the merge function. How can you allow a new debit item to be<br>
merged with an old item that has already been cleared? That is truly a<br>
huge issue. But if you don't set your time frame tight enough, that will<br>
happen, and can you imagine the havoc that would cause in a situation<br>
where there are thousands of transactions a month?</p>
<p>Allowing this function to settle on only a time frame to judge whether a<br>
previous transaction may be merged into a new one is downright crazy.<br>
And very poor judgement. But from experience, it smacks of taking the<br>
easy way out. But again, an unfinished function. Because disallowing a<br>
transaction to be merged into a new one should depend FIRST on whether<br>
it has already been cleared. If it has, how do you offer it up for merger?</p>
<p>Until I figured this out, it wrecked my register several times. I had no<br>
idea I was losing transactions because they were being merged into ones<br>
that were already cleared!</p>
<p>Regardless, I gave up Quicken because I found MD to be suitable for my<br>
needs, without all the muss and fuss that I don't want or need. i<br>
actually enjoy using MD and look forward to it maturing as we go forward.</p>
<p>For me, less is more, and MD fits nicely in that equation.</p>
<p>Kind regards....</p>
<p>dwg wrote:</p></div>amarctag:infinitekind.tenderapp.com,2009-01-14:Comment/460124402018-09-06T01:14:07Z2018-09-06T01:14:07ZReminders<div><p>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..</p></div>dwg