Question Status

Unanswered
Jim Prendergast asked a question on 20 Aug 2010 11:57 AM

We are using Axapta 3.0 with SP6

 We record exchange rates daily in the ExchRates table and while one user has entered and saved a new rate, a second user starts an Invoice. While invoicing a Vendor AX is selecting the Exchange Rate from the previous day.

It appeared that the ExchRates table is being cached so we changed the CacheLookup property on the table to None (it used to be Found).  However, it seems to still be picking up cached values from somewhere.

Are we interpretting correctly or is the Exchange Rate coming from somewhere other than the ExchRates table?

If the second user opens the "Exchange Rates" form (General ledger .. Setup .. Exchange rates), they can highlight the Exchange Rate entered by the first user and click the "Save" button. Then they can start the invoice and the correct Exchange Rate is used.

Thanks,

Jim

Reply
Denis Fedotenko responded on 22 Aug 2010 7:39 AM

Hello Jim !

There is no point in changing cacheing mode for exchRates table, because actually Dynamics AX use application level cacheing of exchange rates, implemented in ExchRateCache class. Moreover, every AOS Server and every DAX client has it own copy of exchange rates cache. There are two methods for flushing exchange rate cache ExchRates:fushCacheClient() and ExchRates::flushCacheServer(). When You hit the "Save" button on "Exchange Rates" form, both these method are being called. I guess, the issue is that when someone is entering the new exchange rate value, it leads to flush of server cache (global for all connections), but leaves every client (spare the client of the user who just changed exchange rate) with outdated copy of cache.So, from the first sight, the only solution for you is to develop some simple job/class, running on client and instruct users to run this job every day at say, 12:30 (when new exchange rate is usually became available).

From other side, I have a strong filling that this issue is caused by incorrect customization. Normally, Axapta does not use client side echange rate cache. Posting classes are run on server side, thus they fetch data from server side cache by default;If some document has user-specified exchange rate (like GL Journal), then system specially calls server-based class to fetch default exchange rate value. (E.g. LedgerJournalEngine.currencyModified() calls ledgerJournalEngine_server.currencyModified(), just because server version of the class has a guaranteed access to most recent exchange rate values). That is why I think that You should ask your developers to check on which tier is being run the logic which sets exchange rates for your vendor invoices...

Regards,

Denis

Reply
Jim Prendergast responded on 23 Aug 2010 8:58 AM

Thank you for the reply Denis.  I was afraid that there was still caching going on somehow, somewhere!

I am one of the developers (not very experienced).  I am not aware of any customization that would have affected a Posting class.  We have tried to avoid making any change to Posting.  That is not to say that we haven't done so without realizing it.  Which Class would you suspect may have an incorrect customization?  Also, how would you test to see which tier (server or client) the logic is being run which sets the exchange rates for Vendor invoices?

Thanks again,
Jim

Reply
Denis Fedotenko responded on 23 Aug 2010 10:16 AM

Hi Jim!

I do not completely understood which way of entering vendor invoice you use. Most probably, You use Vendor Invoice Journal from AP->Journals->Invoices menu. This functionality is a special kind of GL journal and every line of invoice journal has exact value of exchange rate to be used. If journal lines already contains incorrect values of exhange rate before posting, then you should check ledger journal editing support classes (ledgerJournalEngine and descendants). Normaly, echange rate value is being filled in in ledgerJournalEngine.currencyModified() method, which in turn calls ledgerJournalEngine_server.currencyModified() method. The last class MUST run on server tier. Please, check that in class properties, RunOn property is set to Server.

If echange rate value in ledger journal lines is not filled-in during line creation/editing (remains zero), then system use default exchange rate for the date during postng. Please, check that ledgerJournalCheckPost, ledgerJournalTransUpdate (and descendants) and ledgerVoucher classes has RunOn property set to Server.

Regards,

Denis

 

Reply
Jim Prendergast responded on 23 Aug 2010 10:52 AM

Again, thank you. 

The user is starting the Vendor Invoice by:

AP-> Purchase Order .. stand on a PO and then click the Posting button etc...  As soon as the "Posting invoice" form appears, click the Totals button and that's where we see the Exchange Rate.

I hope that makes sense.

btw - I did check some of the classes that you mentioned and their "RunOn" property was set to "Server".

Thanks
Jim

Reply
Denis Fedotenko responded on 23 Aug 2010 10:55 PM

Hello again Jim 

Then, most probable suspect is purchTotals class and its descendants. Please, check that they are marked as running on server. Another possibility, is that someone implemented the logic, which set purchParmTable.fixedExchTate to NoYes::yes and purchParmTable.exchRate to incorrect exchange rate. Please, check in the "Posting Invoice" form the values of two fields on Setup Tab in the lower part of the screen - "Fixed Rate" and "Excange Rate". If first field is set, then You should look for a code which is setting it to NoYes::Yes...

Denis

Reply
Jim Prendergast responded on 24 Aug 2010 1:03 PM

I checked those items that you described ... the classes are set to run on the Server and "Fixed Rate" & "Exchange Rate" fields are not changed (i.e. "Fixed Rate" = NoYes::No & "Exchange Rate" = 0)

Here is something that's interesting in \Data Dictionary\Tables\ExchRates:

static client server ExchRateCache exchRateCache(boolean reSelect = false)
{
    return classFactory.exchRateCache(reSelect);
}

The default for reSelect is false and the exchRateCache method is almost always called using the default.  So, I changed it to the following for a test:

static client server ExchRateCache exchRateCache(boolean reSelect = true)
{
    
return classFactory.exchRateCache(reSelect);
}

When we tried the "Posting Invoice" again, the correct Exchange Rate was being used.  I don't know if there would be a bad outcome in some other functionality of Axapta if we implement this change!

Cheers,
Jim

Reply