Hi Jaroslava,

this was also raised as case on IFS and we get an answer, that this is limitation, what is quite big problem for us, because our legislation require to calculate also this value to inventory value.

Answer from IFS RnD:

• Jayani Weerasinghe

  2024-11-13 04:10:17  Additional comments

  Hi,
  
  Below concern is noted and please find the information received from our RnD team about the raised concern.
  
  Kindly note as per the current system designed behavior it is not possible to provide resolution from support for the raised concern. As previously explained, It was identified as a limitation with the functionality during the Apps 10 project when the functionality (currency revaluation of the GRNI account ) was implemented, and that is why the validation was added.
  
  The support for doing currency revaluation of the GRNI account, which also includes to separate what is the real price difference and what is a currency difference at the time of matching a supplier invoice, isn't possible to do. It is the standard principle in the system that it supports this, since this was demand requested by many customers, before this was finalized during the Apps 10 project. And the only way to support that you can distinguish what is a price difference from a currency difference, is to store the currency from the PO as transaction currency on the inventory transaction. And when an invoice is matched against a receipt, the system will always evaluate both accounting currency and transaction currency to make sure there is a balance on the GRNI account. And this is where it gets extremely complex if one and the same transaction should be able to capture multiple M10 transaction currency postings and to balance everything with the invoices.
  
  But we doubt the concern in reference to cost recognition. The Cost is always in accounting currency. Then if you purchase something in a different currency than your accounting currency, and using e.g. Weighted Average as Inventory Valuation Method, we will calculate the cost for the receipt by considering the PO price and the rate between the PO currency and accounting currency. And as identified by RND it was exactly the same behavior in Apps 8 and the difference from Apps 10 is that IFS post the transaction currency amount acc to the PO currency. For the reasons as mentioned above.
  
  We hope the provided explanation for the raised concern was helpful and kindly note as per the explanation by subject matter experts this has been identified as a system designed behavior and a limitation.
  
  Thanks & Best Regards
  Jayan

Did you try to create PO overhead instead of additional costs? This might be more complex, but I think overheads (like transport) can have its own currency. And you can connect overheads to specific PO line.