8

Historically it's been possible to determine if advanced currency management is enabled by using:

Schema.getGlobalDescribe().containsKey('DatedConversionRate');

as this object is only available on orgs with this feature enabled.

See How to identify Advanced currency is enabled in apex class?

Also, per the docs:

This object is for multicurrency organizations with advanced currency management enabled. Use this object to define the exchange rates your organization uses for a date range. This object is not available in single-currency organizations, nor is it available if the organization does not have advanced currency management enabled.

On two orgs today I found that the DatedConversionRate object is showing up even if advanced currency management is disabled (I don't know if this only happens on orgs where advanced currency management has previously been enabled).

What I'd like to know is:

  1. Does anyone else reproduce this issue?
  2. Can anyone test this on a multi currency org that has never had advanced currency management enabled?
  3. Does anyone know of an alternate way to determine in Apex if advanced currency management is enabled?
  4. Am I missing anything obvious here?

Here's a test class you can use to detect the presence of DatedConversionRate objects. I have tested on APIs back to 32, so it does not seem to be a versioned change.

@istest
public class test1 {
    @istest
    public static void test1()
    {
        Map<String, Schema.SObjectType> gd = Schema.getGlobalDescribe();
        system.debug(gd.containsKey('DatedConversionRate'));
    }
}
6
  • To add clarification to #2: "Can anyone test this on a multi currency org that has never had advanced currency management enabled?" This means an org that does have multi-currency turned on (a feature that is not enabled by default on a new org), but has never had the advanced currency management (dated currency rates) turned on.
    – kibitzer
    Commented Apr 22, 2016 at 18:22
  • I just tried the sample code as anonymous apex on na2. The describe came back for 'DatedConversionRate'. Confirmed that "Advanced Currency Management is not enabled" under setup. I don't think it has ever been on in this Org. I can also do a Select Id from DatedConversionRate. No rows come back, but it appears to be a valid SOQL query, Commented Apr 23, 2016 at 8:08
  • If, indeed, that org has never had Advanced Currency Management enabled, then this is definitely a change in behavior. I do have an org where I can read DatedConversionRate data even with Advanced Currency Management off - my suspicion is that this is an org that previously had it enabled. In any case, as I'm seeing it right now - there has been a change in behavior that renders the previous design pattern ineffective, that apps using that design pattern may be returning incorrect results with nobody the wiser, and that there is no reliable way to determine if this feature is enabled.
    – kibitzer
    Commented Apr 24, 2016 at 0:03
  • If a SOQL query against DatedConversionRate returned no records, would it be equivalent to the feature being disabled? Not as efficient as the describe call. Maybe as a backup option? Commented Apr 24, 2016 at 5:21
  • I'd say that would be a workable solution. I would hope that most people doing their own conversion would already have that form of backup in places (I know that I do). I don't think the efficiency is a huge concern - it's +1 query, and I expect anyone doing these kinds of operations is caching the data for the duration of the execution context anyway.
    – kibitzer
    Commented Apr 25, 2016 at 16:30

1 Answer 1

3

Describe info gets cached when it's first requested. Have you perhaps added some describe logic to your code? Can you reproduce this in a vanilla org? I just ran that code snippet as the test class provided and via execute anonymous in a Spring '16 and Summer '16 org and got false each time.

8
  • 2
    It's not just describe info - in that I can also query on the object (SOQL query should fail with an error), still this is possible - but if so it does represent a change in behavior. Did you test on a multi-currency org? Remember - plan vanilla orgs do not have multi-currency enabled, and those will return false - that still works. If you did see it on a multi-currency org, could you turn on advanced currency management, and then turn it off again and see if it returns true or false? That is a possible scenario - that it only occurs on orgs that previously had advanced currency management.
    – kibitzer
    Commented Apr 22, 2016 at 18:19
  • You can get the same behavior without doing a describe, if you load an object of a certain type in one API version before accessing it in a different version. That said, I am guessing that's not your issue. Since these orgs had multi-currency turned on, it's possible that the schema needs to continue to reflect the existence of this object type to retain data consistency. I'm not 100% certain of that, but it seems a probable explanation. I'm not sure how this is problematic, though...if you see the object type but return no rows, isn't that the same as not finding it in the describe? Commented Apr 23, 2016 at 20:27
  • Ah, but we see the object type AND we get rows returned when we do a query! Also, the behavior change doesn't seem to be versioned - at least, I get the same thing for testing on API 32 and 36. I'm certain that in the past we could reliably use the existence of the DatedConversionRate object to determine if advanced currency management is turned on or not on multicurrency ors. With this change in behavior, there is no way to do so. Worse, any apps relying on that design pattern are now potentially returning incorrect results - but nobody knows it. This seems to me a pretty big problem.
    – kibitzer
    Commented Apr 23, 2016 at 23:58
  • Why do you see this as a change in behavior? When did you begin to see the behavior? And if there are data rows for dated currency, what is the expected behavior? I don't know that area, so I don't know the expected behavior when an org goes from dated exchange rates to no-more-dated-exchange-rates. I can see the answer being that those rates are still in force, because otherwise records that have been calculated in certain ways would suddenly have new values. That could potentially cause serious havoc, possibly more than to your innovative hack which guesses at whether the feature is active. Commented Apr 25, 2016 at 17:06
  • Well, in the past you could reliably use the presence of DatedConversionRate objects to determine if advance currency management was enabled - it was a lot like a RecordTypeID - no record types, no field. That was how you'd know if advanced currency management was enabled. When disabled, one would expect that object to vanish, or at the very least, for no records to be returned. You must be doing something like that internally, as your fields work correctly - when currency management is disabled, the DatedConversionRate data is ignored. But if Apex is still seeing those records, it has ...
    – kibitzer
    Commented Apr 25, 2016 at 17:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .