Recurring Transactions Problems

20 posts
Re: Recurring Transactions Problems

mfarmilo
New MMEX User

Posts: 16
Joined: Sun Aug 07, 2011 4:17 am
I just noticed something, don't know how I missed it ! In the 'Enter next occurrence' screen, next to 'Pay date' (which now will always be set to today's date for some weird reason), there's a button 'reset date to the due date'. If I click this, it sets the date back to what it should be, the one you had the sequence programmed to use. I don't know why it was changed to use today's date instead of the one I'd instructed it to use, but at least this button fixes it to work the way it was intended to.

Also don't know why I'd ignored this button till now - but for the others who have been affected by the weird change, I thought I'd mention this.
Re: Recurring Transactions Problems

Stonyjohn
New MMEX User

Posts: 14
Joined: Thu May 28, 2015 3:46 pm
Location: Milton Keynes, UK
Well spotted, mfarmilo. I must admit I hadn't noticed that. Perhaps it's because it's just a button with a pretty pattern on it without any label.

Having said that, it doesn't alter the fact that the feature promised with version 1.2.1 hasn't worked out. That button also appears on the Edit Recurring Transaction screen. Although the button does what you say, and that is a revelation to anyone trying to work they way they used to with 1.1.2, we still need to press this button before the transaction is executed. We can't "Set to 'Auto Execute' on the next Pay Date". If that next pay date is one month from now, we want it to "Execute" today, showing next month's date, so the transacton appears on the listing as a future payment, so we can budget in advance.

Thanks anyway for ponting out this new button. It does mean I can update to 1.2.1 but will still need to manually "Execute" these transactions one month in advance of the Pay Dates.
Re: Recurring Transactions Problems

paulcroft
Super MMEX User

Posts: 76
Joined: Fri Oct 29, 2010 3:48 pm
Location: London, England
Hi All

It is to be assumed that those of us who use MMEX and its future transactions feature are financially asture and, very sensibly, concerned to ensure expenditure does not exceed income.  However, it is also clear that recent changes to the way the data is added to the accounts has caused some confusion and frustration.

I wonder if you'll permit this 'old geezer' to offer a solution because I resolved this dilemma over 40 years ago, long before home computers, it leads to the peace of mind we seek, and it makes the methodology employed by MMEX (which is the source of the frustration) something of a moot point.

Here in the UK there's nothing to stop you having more than one bank account and, so long as the account's in credit, it's free, so here's what I do. 

1.  I have a second bank account just for bills and call it my budget account.
2.  Having worked out the total of all the bills I will pay over a year I divide this by 12, and I have a standing order from my current account to my budget account for this amount.
3.  All my bills are set up so that they're paid from my budget account, either by standing order or direct debit.

The aim is for this account never to be overdrawn and, to avoid that, it will be necessary, when opening the account, to add an extra injection of cash as well as the first 1/12th of the annual total because, in some months, your bills will exceed more than the standing order but, once you've worked out how much this needs to be, your budget account should never fall into the red. 

This has the advantage that, if you are with the right bank, the surplus should earn you interest - mine is currently earning me 4% AER.

This system resolves the issue with MMEX's method of handling recurring transactions because now you will always know how much is to be transferred out of your current account each month to meet your commitments.  This is, if you like, the first future transaction, set to auto-execute on payday.

In respect of the recurring transactions for your bills these, of course, are set up to debit the budget account and since this should never fall into the red, there's no pressing need to enter these prior to their due date to see what the balance will be in the near future, all you need to do is reconcile the bank's statements with your mmex records as and when they come in.

Of course, this system doesn't alter the way that MMEX handles future transactions but it should resolve concerns about upcoming bills and I find I have no need to enter future transactions in advance of their due date, I simply set them to auto-execute without user acknowledgement.  A glance at the balance in my current account usually tells me what I really need to know.

One other small discipline is necessary with this system.  I run a spreadsheet which lists all my bills and every time there's a change to be made I update the spreadsheet so that I can instantly see how this affects the necessary monthly transfer.  The advent of online banking has made updating this amount a doddle.

HTH
Paul
Re: Recurring Transactions Problems

Stonyjohn
New MMEX User

Posts: 14
Joined: Thu May 28, 2015 3:46 pm
Location: Milton Keynes, UK
Thanks Paul - that system of yours is great, and no doubt works for you. I don't want to belittle your method here, but we all have different ways of keeping our accounts according to our own particular circumstances. The problem with a program like MMEX is that it tries to suit all of us, and seems to be failing in respect of recurring transactions.

My own situation is that I operate more than one bank account with recurring transactions. This is a legacy arrangement, and I'm not about to alter it now to suit the MMEX failing. Also, some transactions are arranged for the future, such as credit card payments, which very from month to month. These are entered into MMEX when the statements arrive and online payments are arranged.

If I used a spreadsheet for my accounting there would be nothing for MMEX to do, and so it would be superfluous. I'm sure the majotity of MMEX users would prefer it to be correctly programmed to do what it is supposed to.
Re: Recurring Transactions Problems

paulcroft
Super MMEX User

Posts: 76
Joined: Fri Oct 29, 2010 3:48 pm
Location: London, England
>> we all have different ways of keeping our accounts according to our own particular circumstances <<
No dispute.

 >> I operate more than one bank account with recurring transactions. This is a legacy arrangement, and I'm not about to alter it now <<
I don't blame you, nor would I.  I was simply trying to offer an alternative that negates the current issues but I agree that, if they were addressed, it would improve the software.

To reiterate, as I see it and as a request to those who kindly write the software for us FoC, please will you consider the following changes:

1.  Currently, when manually entering a recurring transaction the payment date defaults to today's date.  Please can this be amended so that the payment date defaults to the Pay Date as per the transaction record but retain the button alongside so that this can be changed if required.
2.  After manually entering a recurring transaction the highlight currently stays on the transaction just entered.  Please can this be amended so that the highlight moves to the next transaction at the top of the list.
Paul
Re: Recurring Transactions Problems

Stonyjohn
New MMEX User

Posts: 14
Joined: Thu May 28, 2015 3:46 pm
Location: Milton Keynes, UK
Update: With the new version 1.2.2 installed I found that there has been no change to the situation.

In "Recurring Transactions" I have set each entry's "Payment Date" to be the date when I want the next transaction to be added to the account database. I set the "Due Date" to be the date I need the transaction to show in the account database, which is the one applied to the bank account as a "real-life" transaction, placed in the listing one month in advance, so it should show on the list in grey as a future transaction. Instead, the date in the listing changes to the current date, regardless of the date I set as "Due Date" or the date on which I right-click and select "Enter next Occurrence". This is plainly wrong and should be classed as a bug. I can't imagine anyone being happy with its behaviour at present.

I have reverted to version 1.1.2 as the last one working correctly.
Re: Recurring Transactions Problems
User avatar
stef145g
MMEX Developer

Posts: 278
Joined: Fri Aug 13, 2010 9:40 pm
Location: Canberra, Australia
Further discussion on this topic can be found on GitHub issue: Recurring Transactions transfer date
Regards: Stefano
Re: Recurring Transactions Problems

paulcroft
Super MMEX User

Posts: 76
Joined: Fri Oct 29, 2010 3:48 pm
Location: London, England
stef145g wrote:Further discussion on this topic can be found on GitHub issue: Recurring Transactions transfer date
Hi Stef

I've just been reading through the thread on this issue and hope your efforts are appreciated by those who use recurring transactions - a vital aspect of money management. 

My methods and Stonyjohn's are different and that's hardly surprising, everyone will have their own way of handling these things, but it goes to illustrate how difficult it is to cater for everyone's needs.  One thing that struck me particularly was how difficult it can be to convey the purpose of a column unambiguously yet concisely.  Full marks for your solution.
Paul
Re: Recurring Transactions Problems

Nikolay
MMEX Developer

Posts: 2284
Joined: Sat Dec 06, 2008 8:27 am
Location: Sankt-Petersburg, Russia
Re: Recurring Transactions Problems

paulcroft
Super MMEX User

Posts: 76
Joined: Fri Oct 29, 2010 3:48 pm
Location: London, England
Yes, I saw that on the thread Stef linked to.  Very clear and proof that pictures are worth thousands of words. 
Paul
Who is online

Users browsing this forum: Bing [Bot] and 5 guests

cron