Vendors conflicting problem at purchase invoices payment

I attached the problem summery pictures to easy describe the problem , 2 pictures showing same vendor account summery and last purchase invoice,
since the last August update manager this problem came up at the purchase invoices payment.

You havent said what the problem is.

The images seem ok,

the problem its clear at the purchase invoice with less payment. the balance due different on the summery balance

The balance due on the invoice is just that. The balance due in the summary / accounts payable/supplier is the supplier’s balance.

There is no reason to suppose they should be the same. Some payments may have been allocated wrongly to other invoices so they are overpaid
You need to look at all the transactions on the supplier’s account to check how the payments were allocated

Top screenshot isn’t attempting to show ‘balance’ of any transaction, it’s just a list of all transactions that hit the AR GL account. Looks fine.

Look at an aging or AR report which shows transaction balances .i.e. net invoice balances after application of payments.

Two distinct views of the make up of AR but they should add up to the same total.

I think you are misinterpreting the top screen as showing open transaction balances. It isn’t.

First of all, @maldroubi, the balance due on the purchase invoice and the balance of Accounts payable for this supplier are not supposed to be equal. The first is the balance of an account. The second is an amount due on a single purchase invoice.

Beyond that, I see three possible issues, @maldroubi:

  • I suspect you may be wondering why payment #1416 is posted against purchase invoice #12560. To answer that, you must show a screen shot of the Edit screen of that payment. There seems to be a mismatch between an available credit as of 22/09/2019 and the amount automatically applied to purchase invoice #12560. But the payment Edit screen is a necessary piece of the puzzle. Read Resolve automatic credit allocations on sales invoices | Manager.
  • I also wonder why you have journal entries posted to Accounts payable. That would be unusual in Manager, as transactions involving movement of money into or out of the business should not be recorded with journal entries. As a result, journal entries are quite rare.
  • If your last update was in August, you should update again. You are at least 50 versions behind, and possibly more.

@Joe91 I did not say the balance it should be the same, but the invoice should have no less payment since the vendor account summery show its “credit” and it was the last record.

thank you @Tut ,


you got the problem point, ( the invoice should have no less payment since the vendor account summery show its “credit” ) I attached the screen shoot for the #1416

some times we have to do a journal entries, in that case the vendor doing payment on behalf of our company to another vendor ,

we always keep updating . but I mention that the problem it came up in that date only

I think your problem is related to mixing currencies. The customer in question is denominated in USD. The account you paid from is in AED. Posting to the supplier’s subaccount in Accounts payable will be determined by the exchange rate.

@Tut before the august update was no issue in multiple currencies, specially we are dealing with many currencies and our base currency in MANAGER is USD. all sales and purchase invoice was exact less payment according to the payable balance.
I changed the payment currency as you mention to see the result, unfortunately its the same even changed to other currency.
not only this purchase invoice its had ( less payment ) issue. but we thought its will be fixed in new upcoming update.

I do not understand what you wrote in your last post. Let me explain in more detail.

You have a supplier denominated in USD. So the purchase invoice for that supplier is in USD. This translates exactly to the supplier’s subaccount in Accounts payable because your base currency is USD.

But you already had a supplier credit with that supplier because of a payment in AED. This would have moved that supplier’s balance in Accounts payable in a negative direction. The calculated effect on Accounts payable would have been converted to USD based on the exchange rate you had in effect. It looks like that was about 3.67AED = 1USD.

You did not specify a purchase invoice for payment #1416, so Manager would have applied it to open invoices for this supplier in order of due dates. Those postings would also have been subject to exchange rates in effect. You have mentioned that journal entries are necessary because this supplier pays on your behalf to another supplier. But you have not shown any of those. They might also have involved various exchange rates.

You have not said so directly, but I suspect you might think 393.00 USD should have been applied to purchase invoice 12560. If you only had purchase invoices and payments, and every bank account and transaction was denominated in USD, that would probably be correct. But your situation is too complicated to understand without being able to trace every transaction, journal entry, and exchange rate all the way through your records. That is your job.

can not 393.00 USD been applied to purchased invoice 12560 since the 393.00USD its “credit” !!!

this not what I meant. last payment as account statement of that supplier is US$ 15,972.75 so. the balance is US$ 393.00‏ " credit "

we made purchase invoice US$ 6,785.52 how it show " less payment " once the account balance is US$ 393.00‏ " credit " ???

I had other version of manager with AED base currency " For audit check " . the result its the same No matter the difference of the currency exchange rate

As I said, I cannot offer further information, because there is much more that affects these transactions than you have shown. In fact, there is probably more than you can show on the forum. I have tried to suggest possible reasons for the behavior, but you will have to examine your records yourself.

@Tut I am appreciate your effort. we check all the records,transaction and all entry , unfortunately nothing wrong, I believe its programing issue. as I mention previously every thing was perfect once the new update this problem its came up.

Can you create a test business and enter dummy data to illustrate the issue?

The simpler case may better identify any underlying problem in the program or how it is suppose to behave

will try