MoneyManagerEX_SVN-3085 - Major mistake in Un-Reconciled

[lotsofjunk]

I have MoneyManagerEX_SVN-3085 installed on my Win7 desktop and found this major mistake in the un-reconciled view running balance.
When I view the reconciled view, the running balance in my legder is correct.
When I view the un-reconcilded view the totals end up correct, but individuals balances are incorrect.
From the snapshot you can see that a $777.25 - $52.52 does not equal $41.07.

Un- Reconciled view

View Unreconciled.JPG (15.64 KiB) Viewed 9538 times

Un- Reconciled view

View Unreconciled.JPG (15.64 KiB) Viewed 9538 times

[GregChapman]

You misunderstand the report.

The balance at the date of the transaction is correct according to the transactions you have entered.

The balance will not alter simply because you choose not to show the transactions that have not yet appeared at the bank.

[lotsofjunk]

No disrespect, but you are abosutley wrong.
$777.25 - $52.52 does not equal $41.07
When a transaction is reconcided it does change the balance. This is error is not caused by changing views, it is not displaying a reconciled balance correctly, in the unreconciled view.
Here is a screen shot of .0.9.8.0 with the same database, un-reconciled view, and notice that the math is correct.

[GregChapman]

I have only been using the program since 0.9.9.0, so cannot speak for the behaviour of 0.9.8.0. What I can say is that there has been no change to behaviour in 0.9.9.2.

In these two versions, all you are doing when you filter a view is removing certain items from the view. The hidden transactions remain in force and the calculation of the balance remains as before. This is why I said you misunderstand the report. Whether this counts as a "major mistake" or was a deliberate change in function, I'll leave for others to decide.

[lotsofjunk]

I have been using MoneyManageEX since November of 2005, I can't remeber the version number.
I did install .0.9.9.0 but it had lots of issues (crashed when I tried to update options) and I unistalled it and re-installed .0.9.8.0, other wise I would have reported the running balance issue. Didn't use it long enough to notice this perticular bug.

From the screen shots I have posted, you can tell that it is not merely a view selection that is causing the problem, but a calucaltion.

This is a great progam, and hope to continue using it, but when the balances viewed are incorrect, it is un-useable to me.

I have un-installed MoneyManagerEX_SVN-3085, and started using .0.9.8.0 agian.

Thanks for a great program.

[GregChapman]

I think I appreciate what you seek, but I would still say that the 0.9.9.0 behaviour is acceptable and even correct.

When you reconcile an Account (a technical term) with another, you are confirming that they match. If you ask a program to filter (i.e. just hide NOT delete) the account to show unreconciled transactions it won't affect the Balance (another technical term with a specific meaning) of the account.

With a filter in place, the Account screen does not magically convert to a list of transactions with a running total. If you wish the Balance of an Account to be recalculated then you need to edit the transactions in that account. In short, a Balance column has little meaning when a filter is in place as the figure does not relate to just the remaining transaction in view.

In other words, you need a Report if you want to see a list of unreconciled items and their total value.

[lotsofjunk]

Lets K.I.S.S.

The un-reconciled view display is incorrect, no matter how you try to justify it. It was correct in 0.9.8.0. and all previous version.

I do not need it corrected, I will just have to stay with 0.9.8.0.

In the UK, $777.25 - $52.52 may equal $41.07 but is the US it does not.

[GregChapman]

In the UK, $777.25 - $52.52 may equal $41.07 but is the US it does not.

OK! Let's keep it simple...

The Accounts screen you show does NOT show the result of the calculation: $777.25 - $52.52
It shows the result of the calculation: $777.25 - $597.37 - $86.29 - $52.52

You selected to REMOVE FROM VIEW certain of those figures. That's all! You did not delete or re-calculate as if the hidden items have been deleted or change the screen to show a running total of unreconciled items.

The top of the screen tells you the transactions that are not in VIEW. Note the word is VIEW. No transactions posted on the account are excluded from the calculation and the Balance remains accurate for the date indicated!

It just isn't want you are used to - but that doesn't make it a major mistake in the calculation. The information you appear to want can be obtained from the Transaction Report. You need to use the right tool for the job.

[stef145g]

What Greg is saying is correct.

The individual balances represent the true running balances in date order.

The way the balances were displayed in 0.9.8.0 was incorrect, when I attempted to reconcile my statements with MMEX. This is the reason for changing it in 0.9.9.0 because the balances kept on changing depending on what was being displayed as I was changing my transactions to Reconciled.

This can be proved like this:
1. While viewing all transactions, select a transaction, and notice the balance.
2. Make the transaction before this date as unreconciled.
3. Change the view to show Reconciled transactions.
The balance of the transaction for the selected date in point 1 should not change.

This way the user can quickly identify the transaction is correct with the correct balance as shown on the statement, provided that they are in the same order. This is still a problem with multiple transactions occuring on the same day being out of order to the statements.

[lotsofjunk]

The way a single line ledger is suppose to work is that:

1. You have a balance
2. When you have a withdrawl on the ledger line : Balance - with drawl = new balance.

At least, that is what I was taught in accounting in the late 70's.

The un-reconciled view in .0.9.8.0 was correct and a ledger. When you go down the ledger : Balance - with drawl = new balance ; this happened in both view all and un-reconciled view.

The current un-reconciled view in .0.9.9.0 should not be displayed as a ledger. It is some strage hybrid, where it is ok to display 777.25 - 52.52 = 41.07.

I undersand your position, but it is incorrect for a ledger!

I will certainly stay with .0.9.8.0, because it worked correcly for years in the past.

[stef145g]

1. You have a balance
2. When you have a withdrawl on the ledger line : Balance - with drawl = new balance.

Unfortunately I am attacking this issue as a programmer, and I agree with your definition, of which other views did not conform to this definition.

Before I made the changes, others also brought to our attention that the balances were incorrect in some views.
For the un-reconciled view, my issue was raised that the report is either:
1. A ledger of un-reconciled transactions.
2. A general ledger with a view showing the unreconciled transactions.

I chose option 2, because to me, I concidered it to be logical, especially with the introduction of the transaction filter.

Not being a financial person, I don't understand the reason for showing unreconciled balances as a ledger as you require.

[lotsofjunk]

Thanks for the answer.

But I still recomend that the current unreconciled view is not working the way a single line ledger should work and it should be corrected or deleted.

It is much worse to display wrong information than not display information.

[GregChapman]

I undersand your position, but it is incorrect for a ledger!

I don't think there is any difference between us when it comes to ledgers. The difference is in what the filter is doing.

In 1970s terms, your concept of MMEx's ledger filter is that of using Tipp-Ex to obliterate an entry AND all following balance entries so you can re-calculate and re-write a corrected ledger, but then use the magic of computers to remove all that Tipp-Ex. You see MMEx's filter as a ledger re-write.

Forget Tipp-Ex. Think Highlighter Pen.

The ledger is NOT re-written and re-calculated. All the original entries remain in place - so no balance will change - it's just that it temporarily only shows highlighted entries.

Stick with 0.9.8.0 by all means, if it works for you, but if you do need to update you'll have to come to terms with MMEx's "highlighter" and use the Report facility to get an equivalent of the display you seek.

[lotsofjunk]

In 2012 terms, you answer is British BS.

Filters or highlighters you can't justify displaying wrong calculations.

.0.9.8.0, worked correclty and I don't need some BS about highlighters!

1. Credit Entry : Balance + Credit = New Balance
2. Debit Entry : Balance - Debit = New Balance

If you highlight what you have done in .0.9.9.0 from the images I have attached, you would notice that the math does not add up.

.0.9.8.0. for Me!

[lotsofjunk]

Once again thanks for you answer, Here is the short answer and I have attached a pdf document with the long answer and an example.

1. The view all - is a check book ledger sorted in the order that the transaction started or entered into the ledger.
2. The view un-reconcilded is a view in the order that the bank cleared the tranaction (reconciled) and this view has always matched by statement line for line.

[stef145g]

Unfortunately I am attacking this issue as a programmer

and as such I need to understand the problem before I can formulate a solution, This is the reason for getting others to test the program and provide feedback to ensure that we get it right.

Here is the short answer and I have attached a pdf document with the long answer and an example.

Thanks for taking the time to explain the concept, as now I understand the reason for it, and makes sense.

From what you are saying, the View Un-Reconciled, should recalculate all the balances for this view. Should this be done for all these other views: View Reconciled, View All Except Reconciled, View Void, Flagged and Duplicates.

The view Transactions items should keep the balances of the general ledger intact which it was not doing.

When it comes to the transaction filter usage, I would prefer not to have the balances recalculated when different statuses are required. (This would also provide a solution to my initial issue.)

[lotsofjunk]

Thanks stef145g, Really appreciate you efforts. Just for info, I have worked with the RAAF Magpies in the past and really impressed with Australia.

I beleive that the View all (primary ledger) should allways be in the orginal entry form. It needs to be a history of transactions and an accurate running balance. All verions of Money Manager EX verisons that I have used has done this exceptionly well.

I only use the View all and view Un-Reconciled, so I really can't speak for the other views.

From what you are saying, the View Un-Reconciled, should recalculate all the balances for this view.

My opnion, but I am pretty positive that to display in a ledger format, there is no other option, but to recalculate balances.

Just a question, but are the concerns with the balances not matching because people are confusing balance (view all - ledger) with re-conciled balance (View Un-Reconciled)?

[Nikolay]

My suggestion to add a button before an account name

ABC Bank

If the button pressed (or became in focus) some info screen appears.

A line with balances info that is under transactions list may be removed.

[stef145g]

I have built the .exe file for Windows at revision 3107 for testing.
Available for downloading on Sourceforge.net: https://sourceforge.net/projects/moneym ... _unstable/

This changes the way that the balances are calculated for:
1. View Reconciled
2. View UnReconciled
3. View All except Reconciled.

Note: This is only the EXE file and should replace the existing file in the SVN-3085 installation.

[GregChapman]

Mmm! Having read the ledger.pdf file, I'm not sure that it explains anything, except to re-state the point that a bank's records will be different from your own, which we all realise.

It comes down to the basic concept behind the program.

It doesn't strike me as odd that MMEx holds MY ledger and when reconciling entries with someone else's records there will be differences in the balance shown for any particular date.

It seems that earlier versions of MMEx had the assumption that MMEx was trying to keep a duplicate of the BANK's ledger. If that's the case then I recognise there might be a need to do recalculations when hiding certain transactions.

However, I assume that like the paper records I held before I computerised my own accounts, my accounting program was recording MY ledger - not someone else's. When I mark transactions as reconciled it is only the transaction that I'm interested in NOT the balance, as I fully recognise that the bank's balance cannot be expected to keep in step with MY records. The balance column is redundant and I would argue that there's no point in showing it at all - then this issue goes away.

As I said before, if you want an indication of the running total of transactions outstanding at the bank, you turn to MMEx's reports facility. What else is relevant if MMEx is recording MY ledgers?

[jamie]

I am firmly on lotsofjunk's side on this one and would like to see this change in the next official version.

[lotsofjunk]

Mmm! Having read the ledger.pdf file, I'm not sure that it explains anything, except to re-state the point that a bank's records will be different from your own, which we all realise.
It comes down to the basic concept behind the program.
It doesn't strike me as odd that MMEx holds MY ledger and when reconciling entries with someone else's records there will be differences in the balance shown for any particular date.
It seems that earlier versions of MMEx had the assumption that MMEx was trying to keep a duplicate of the BANK's ledger. If that's the case then I recognise there might be a need to do recalculations when hiding certain transactions.

Screen shot of other programs that work the way .0.9.8.0 does. Not just my idea. Recommend to go back to .0.9.8.0

[GregChapman]

Screen shot of other programs that work the way .0.9.8.0 does. Not just my idea.

I understand that you want a recalculation when hiding certain entries. I understand that others may do it that way. But you don't explain the advantage when hiding certain transactions. So far the justification amounts to - it's what I'm used to.

I don't understand is what this recalculated balance represents or how it helps in reconciliation. It isn't the balance according to my ledger or that of the other. It doesn't help in spotting reversions, where, for example, one ledger shows an item at £45 and the other £54. (The £9 difference will show up in the balance column whether recalculated or not. Back in the 1960s when I worked in a bank that still used hand-written ledgers it was a favourite party piece of senior staff to check whether a difference was divisible by nine - a sure indication that an error was a reversion!)

When I attempt to reconcile two sets of debits and credits all I am interested in is whether the items, or maybe combinations of certain debits and credits, match in both sets of records. They may show different dates for the various transactions and certainly different intermediate balances if they have been posted in a different order. The balance at the various dates of the unreconciled items is utterly meaningless.

I'm clearly missing something. What meaning or benefit does a recalculated balance offer?

[jamie]

It allows MMEX's balance column to follow the bank's balance column when "Viewing All except Reconciled Transactions", without having to change transaction dates to match the bank's date. If a check clears early, I want to know the impact of that check on the MMEX balance column without having to change the date of the check transaction in MMEX. The account balance could potentially go negative due to a check clearing early and the order of deposits and withdraws that follow. Recalculation of the bank balance would allow you to see that in the MMEX register. In practice, this will never happen to me because I always keep a buffer in the account.

[GregChapman]

If a check clears early

Ah!

I always post payments (cheques, direct debits, etc) into MMEx on the date of issue or when due. Payments can never "clear early". I also enter what I expect to receive in order to gauge my future balance. Normally, I have, at most, a couple of receipts per month.

I check on-line at my bank regularly to confirm that my records match the bank's. I will use a filtered view in MMEx to exclude those items marked as reconciled on previous visits to the bank's web site. Frequently, the transactions that remain in view will show in a different order (direct debits and standing orders are often delayed at weekends) but it is simple enough to mark matching transactions reconciled. In some cases, particularly direct debits and receipts, I may need to edit the amount or date to reflect the bank's records. After I make any edit, I hit the "R" key and the transactions disappears from view. At no time in this reconciliation process do I have any need to look at the balance. It is a complete irrelevance.

I could not foresee the possibility of "checks clearing early". It cannot happen under my regime. This is why I am unconcerned about the balance column. It's not that I have an objection to MMEx reverting to its old way of doing things. I just couldn't see a reason for needing that change.

Being financially relaxed comes from anticipating bills, not allowing a bank to take it from you unexpectedly!