[17.9.28] Improvements to automatic credit allocations

My suggested approach does not require any knowledge of what was done previously. The approach reveals what was done by isolating the overpaid invoices. It was the best I could offer at long distance.

You also did not say whether you had verified that your software is up to date.

I’m sure @lubos will now sort things out for you.

That’s true. But we have adjustments done with inter company based ledgers, hence its unnecessary for us to now go back to past audited entries and rectify the mess caused by Manager update. Yes, Lubos is looking into my file.

Thanks for your kind help!

My old Payment having issues after latest updates. showing “operpaid” but i havnt selected any invoice for that payment.

Screenshot from 2017-11-28 11-13-49

click on the blue figure under the Balance due column for the overpaid invoice and check if there are more than one payment transactions for the same invoice.

Also, have a look at this guide: https://guides.manager.io/12951

What??? @lubos finally changes his profile picture?
This is not happening… :smile:
Look at his face, this guy is one of the smartest people on earth now. :wink:

He MUST be good looking. He’s Australian!

Please see the picture that payment is not allocated to any particular invoice. I did this transactions on 2015. There was no issue until last two three updates.

please understand that your intention to record a payment for an invoice is different from what payment has been actually allocated to the invoice which is showing as overpaid.

your screenshot is showing the payment against the invoice but only you know that. Manager shows data according to what you have entered. you must have wrongly allocated some other payment receipt to this invoice. have you tried what was suggested earlier?


I like it very much now that I can choose between allocating the payment to particular invoices myself and letting it done automatically by the system when I do not select any invoice. This is extremely helpful when someone pays a lump sum or when I pay in bulk.

I found that automatic allocations change the General Ledger Summary report. They double the amount in the Accounts Receivable/Payable. Here’s the example.
I created two Sales Invoices (120.- each) and then received one payment (240.-):

When I allocate the payment to invoices then the GL Summary report shows as it should be:

When I do not allocate the payment to any invoice, and the payment is automatically allocated then the report doubles the amount in Accounts Receivable (480.- instead of 240.-), and the drill-down Transactions list shows as if there has been three payments from that customer.

So now the GL Summary Report does not match to the GLTransactions report. The same happens with Purchase Invoices and Accounts Payable.

I remember that in some older versions the GL Transactions report was also crowded with automatic payments’ transactions, and I like that now this is not so. The view is much clearer now. But I would like it very much if the debits and credits in GL Summary report would match to those in the GL Transactions report.

Thank you for the work you do!

I think what you are seeing is the effect of receiving the 240.00 amount and applying it to the invoice with the oldest due date, then, because that invoice becomes overpaid, reapplying only 120.00 of the receipt and moving on to the next invoice to apply the remaining 120.00. That’s just the way automatic allocation is implemented. Remember that Accounts receivable and Accounts payable are made up of individual subsidiary ledgers for various customers and suppliers, even though just the control account shows in the General Ledger Summary.

The important thing is that when the program finishes with its logic, account balances are correct. And if you view the different transactions in the drill-down list, you will not find additional transactions you did not enter, just the one source transaction.

If you were entering the amounts manually, you could inspect the balance due on an invoice before posting that part of the amount to an invoice. Manager’s method is different, but achieves the same end result. The program uses the overage to determine how much is available for posting to another invoice. Its only method for accomplishing what you can do by inspection is to perform the arithmetic.

If that is true then wouldn’t the GL “Transaction” report be the one showing all those steps as transactions, but it isn’t, the GL Transaction report is showing the correct posting information, but the GL Summary report (automatic distribution) - which should only be a summation of the GL Transactions report’s transactions - is duplicating a particular set of data based on how that data has been processed.

A user on requesting a GL Summary report would be trusting to receive a consistent report output regardless of any processing methods they may have used, i.e. they shouldn’t have to test and validate if the report’s data is accurate or not before they can rely upon it.

E.g. if a user uses a mix of both manual & automatic payment allocations, then their GL Summary report’s Accounts Receivable & Accounts Payable figures will be garbage, can’t be relied upon for generating any other management requirements.

I can’t dispute what you say, @Brucanna, because I don’t know exactly how the process is implemented. But I suspect there is leftover code from before the process was changed to eliminate automatic carry-forward when an invoice is designated. In other words, I suspect the process starts out the same now as it did before, but that the overpayment test was inserted into an existing string of instructions. That’s not as clean as if you began from scratch to code the current behavior.

As for what the GL Transactions report shows, we don’t know, because that isn’t what @Naine posted for the second case. Instead, we are seeing what looks like a drill-down on Accounts receivable balance from the GL Summary. So you may be right. But since we don’t know either the exact sequence of instructions the program executes for automatic allocations or for generating these reports, it isn’t possible to predict what you should see.

But they did clearly state - “So now the GL Summary Report does not match to the GL Transactions report”. If (?) there was also a similar issue with the associated GL Transaction report then I am sure that would have been noted.

If a user selects a specific report then they are “predicting” what they want to see and that’s should include consistency, not a variable result due to different flawed handling.

The point is this - its not what “we” need to know or what “we” don’t need to know exactly - as one’s speculation on cause is irrelevant. The user has clearly illustrated an issue within that report.

For users to have faith in this report then this needs to be elevate as a Bug, but not the elevation of the whole release.

I agree consistency would be desirable. Just because I think I know why something happens doesn’t mean I like it. And I can definitely support the displayed transactions being understandable. I don’t think one should need to know the inner workings of the code or the history of development to make sense of a report.