Hi, what is the version of IFS Application?

Apps 10 UPD 6.

I believe there is correction through bug fixes on this, however I cannot remember the UPD either 5 or 6. Certainly after 7 it has been corrected. Hope it helps.

Where can I search for the potential bug fix?

hmmm that I don’t know. if you contact your local IFS Support, they may be able to help.

Hi, this is patch in UPD 7, see solution  274137  if you have access, otherwise inform the local IFS Support. Hope this help.

Thanks, I’ll have our Tech take a look and report back if it resolves this issue.

Just an update on our investigation into solution 274137 and whether this addresses the issue regarding GRNI not reversing properly in parallel currency.  Solution 274137 addresses a different issue regarding purchase price variance and currency rates not calculating correctly due to some rates being inverted rates and others not.  In our case, parallel currency rate is calculating correctly, but reversing amount for GRNI should reverse the entire original amount, not the calculated amount in the next period’s parallel currency rate.  Otherwise, balances remain in the GRNI account in parallel currency. We will submit a support ticket with IFS.

To close the loop on this, IFS Support said that there is no existing solution to this problem.  The response provided:

“In CORE, there is no such support to handle balancing of the GRNI account in parallel currency.

As you may know, before Apps 10 there was no support to handle anything else than accounting currency from a GRNI perspective, since the whole basis to be able to handle the reconciliation is that we actually have posted amounts in other currency than accounting currency already in our inventory transaction history for all the transactions that post against GRNI, typically ARRIVAL using M10. But before Apps 10 it was only possible to post accounting currency amounts for GRNI. I.e. even if you have a Purchase Order in a different currency than accounting currency, when the postings are created during receipt, posting M10, the system would post the same amount in both accounting currency and transaction currency. So if you query in Inventory Transaction History in Apps 9 or earlier releases, the only columns displayed in the Accounting tab is Debit and Credit Amount columns.

Then during the Apps 10 project an implementation was done to handle also posting transaction currency amounts for GRNI, i.e. that we will use the currency from the PO and actually calculate the transaction currency amount using that currency. So that is why you now also see the new columns for Debit Amount Curr and Credit Amount Curr if you query in Inventory Transaction History and check the Accounting tab.

But there is no similar handling for Paralllel currency. The amounts in Paralllel currency are not calcualated during any Purchase receipt, nor in any context in Supply Chain. The Paralllel currency amounts are only calcualted by Finance once the postings are transferred to Finance, and they create the MPL voucher,

So when you say in step 3 that the amount in paralllel currency for M10 in CAD is 1176,47, then there is no place in Supply Chain that this value is known. And to be able to handle reconciling GRNI during invoice matching, it is necessary that all information exists on the inventory transaction, since that is the basis for calculating price differences or currency rate differences and create the necessary diff postings in the supplier invoice.

Supporting balancing the GRNI account in Parallel currency therefore would require some similar implementation as was done during the Apps 10 project to handle balancing Transaction currency, and which we spent appr 5 months dealing with.

So there is no bug to be qualfied in this context, as assumed here, since this requires some new design to handle.”  End of IFS response.

However, as a workaround I was able to resolve the problem when creating the Manual Supplier Invoice by first changing the voucher date in the header to a date in the same currency rate period as the receipt date, doing the PO matching and then changing the voucher date to the correct date in the current period, save then post.  The AP user must be mindful of this potential problem when entering the invoice.