Hi,

The first question is in which currency the PO was done ?

And then in which currency the ARRIVAL transaction for this PO was done ?

There is difference between APP9 and APP10 in this area.

I think that PO received in APP9 should be matched with invoice in APP9.

Please check currency in the ARRIVAL transaction.

Best regards,

Małgorzata

Hi @Andreas_M 

Sometime back I had to deal with a same scenario with a customer. This reply was previously posted to another question regarding Balinvrou in the community. There are occasions where Balinvrou gets created incorrectly. Some solutions are still in progress to solve this problem and there are several patches that have been released already. You should submit a support case to Distribution mentioning the same. 

But this explanation is to answer your question how and why a Balinvrou get created. In the ideal world the GRNI account should be balanced after fully invoicing. But if you are dealing with parts with prices with decimals, you have conversion factors involved, you do partial receipt or partial invoicing, then in the end they may still not be balanced and that is why we wanted to make sure that the GRNI account is always balances when the Closed date is set, and the record is no longer appearing in the GRNI report.

So, it is expected that the system can evaluate if there is still some remaining value that needs to be cleared at the time when a Closed Date is automatically set by the system for a given Purchase Receipt. New business event and transaction should be added to balance the account.

BALINVROU + Balancing invoice amount postings after rounding - Shortage Found - Debit M19 Credit M10

BALINVROU - Balancing invoice amount postings after rounding – Excess Found - Debit M10 Credit M20

Here we are supposed to use the + event whenever we find that M10 needs to be credited, since the value on M10/M14 is too little compared to M18, hence we see this as a shortage. And consequently, we should use the – event when M10 needs to be debited, since the value on M10/M14 is too much compared to M18, hence the excess.

Additionally, when there are no receipt postings at all, we earlier failed to identify which is the transaction currency. And we need to know which is the transaction currency to be able to create the correct supplier invoice postings and also to know how we should deal with the Balinvrou functionality. The Balinvrou transaction is expected to be created when a Purchase Receipt is Closed as a result of being fully invoiced and yet when analyzing all the postings affecting the GRNI account, there is still some unbalance. An unbalance that should be a result of the mathematical calculations that take place and where you may end up with some rounding difference due to how roundings are applied. So, this has nothing to do with parallel currency.

This happens since all the time we must round any calculated amount to 2 decimals in the application as it is the maximum no of decimals an amount can have.

Hope you got a better understanding regarding the issue.

Best Regards,

Peshala

@Andreas_M

Furthermore as per the information provided it seems like you are in APP10 UPD 11 ? If that is the case the support case which I had to deal was sorted with a patch which is available with the UPD 13. I can’t guarantee that the same patch would resolve your issue. But you should submit a support case to Distribution queue mentioning your issue as you won’t be able to get a solution through the community.

Best regards,

Peshala