As you can see in the first pic the invoice is fully paid
but in the following pic the invoice is unpaid, which is right
Something is wrong
No, the invoice is not unpaid. The balance of Accounts receivable just happens to be the same as the amount of that particular invoice. Your second screen shot does not show invoice status, it shows transactions and balances for the Accounts receivable account.
The 09/01/2019 receipt shown on the sales invoice looks like an automatic allocation from undesignated amounts credited to Accounts receivable. The suspicious transaction to me looks like the 23/11/2018 payment. Why is a payment being posted to Accounts receivable? According to your 2nd screen shot, you never actually received any money against invoice 19-004.
On 23/11/2018 the customer made a deposit of 958,39 instead of 582,80 so he requested refund the amount of 375,59, which was right, so on 23/11/2018 the due amount is 0
the invoice 19-0004 on 09/01/2018 is upaid, in this case the first screen shoot (the due amount at the end of the invoice is wrong)
OK. Now I understand what happened in the real world. To understand what happened in Manager, go to the Sales Invoices tab and post a screen shot of the portion of the register that includes INV19-0004. Then click on the balance due figure for that invoice and post a screen shot of what you see.
Does anything show under the Receipts & Payments tab for the receipt on 09/01/2019? Based on what you’ve written so far, I suspect nothing will be there.
I would try deleting the sales invoice and re-entering it to see if anything is applied automatically.
No Nothing, I suppose it must be fixed from @lubos
I cannot reproduce this. And no other user has reported this problem. If it was a bug, I think hundreds of complaints would have come in. Basically, you are saying Manager is spontaneously applying nonexistent receipts to sales invoices. I think somewhere you have a transaction that is causing this problem.
ok, then where is it and if so why in the customer report shows there is a due amount?
If I knew the answer to your question, @pandhm, I would answer it. Only you have your accounting records. If you have backups from before this problem appeared, look among the transactions entered since.
Nice,
So I think its a bug, because as soon as I correct the records on 23/11/2018 to 582,8 making the subtraction manual (958,39-375,59) everything returned to normal.
@lubos should be informed I think
Corrected where? And why do you say “corrected?” Was something wrong? What happens if you restore whatever it was to the way it was before? It is possible you had a number format problem or originally entered a number incorrectly.
Come on @Tut, I think is clear,
on 23/11/2018 there were two records
one receipt of 958,39 and one payment of 375,59. the total for this date is a receipt of 582,80.
So now there is a receipt of 582,80
and everything is ok and the due amount on the invoice is right
It may be clear to you, @pandhm, but not to me. Are you saying that your original entry of the payment did not happen? You did not mention in your earlier post that you had actually deleted that transaction. You wrote that something had been corrected. Which is it?
If you actually received 958,39 and paid 375,59 in separate transactions, they should be entered that way. If the program cannot handle that, there would be a bug. But to confirm that, you would need to show the Edit screens of all transactions involved and the erroneous results. So far, the information you have provided leaves the possibility of mistakes.
It’s funny.
Of course you can keep your mind, but I still think that there is a bug here
You might be right. But if you won’t provide answers to the questions asked, it cannot be investigated.
@pandhm, it did not occur to me until the bug fix of version 19.1.18 was announced: Mishandling payments against customer starting credit balances - #9 by Brucanna. The bug report was specifically about starting credit balances. But that problem might also be responsible for what you were seeing.
Try updating your software and re-entering the transactions as you originally had them. See if the problem is resolved. If so, you were right about it being a bug. This one took a very long time to fix.
Solved.
So it was a bug