function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
lifewithryanlifewithryan 

Custom Settings & Currency Field Type

I ran across something interesting today and was wondering if anyone has seen similar behavior.

For a current project I have some custom settings that is used to set a configured unit price (hourly cost) on a provided service.  I also have a custom Request object and a custom Request Item object. Each Request is made of up one or more Request Items that may incur multiple costs based on work performed. These items are rolled up to the parent and then a trigger is used to calculate the cost of services rendered and from that an invoice is generated.

The trigger retrieves these base costs from the custom settings. The kicker here is that the custom settings has those field types set to Currency.  When I retrieve them and subusequently use them in a mathematical equation such as: Total_Admin_Hours__c * settings.Admin_Hourly_Cost__c, I get an exception stating that the arguments are illegal.

I verified that it was indeed the settings that it was choking on by hard-coding an arbitrary decimal value and it worked. After many head-scratches, I finally changed the custom settings field types to Number instead and everything worked as expected.  

Is there something going on inside the big black box that I'm not understanding fully or did I find some sort of "bug/feature?"

Incidentally, I wrote a unit test to verify that indeed it didn't like Currency. Something like:
@isTest static void test_decimal_multiplication() {
     RequestSettings__c settings = TestUtility.createSettings(null); //nothing to see here ;)
     Decimal total = 1 * settings.Admin_Cost__c; //Admin_Cost__c is set to 1.00 in custom settings
     System.assertEquals(1.00, total); <---- this actually passes if I remember correctly

--BUT--

  RequestSettings__c retrievedSettings = RequestSettings__c.getInstance();
  System.assertNotEquals(null, retrievedSettings.Admin_Cost__c);
  System.assertEquals(1.00, retrievedSettings.Admin_Cost__c);
  total = 1 * retrievedSettings.Admin_Cost__c;
  System.assertEquals(1.00, total); <--- fails if field type is Currency, passes when Number
}


Thougths? I'm not ruling out the possibility that I mucked with something else and magically it worked, but it definitely wasn't liking the CURRENCY setting...I will probably try to reproduce this in a dev org somewhere just to clear my head, but was hoping maybe someone had a nugget for me as to why it would fail if Currency is supposed to be a Decimal anyway...
@LaceySnr - Matt Lacey@LaceySnr - Matt Lacey
I don't really have anything to say of particular use except for the fact that you're not alone... I've seen some really weird behaviour around the use of decimal fields from custom settings which I've detailed here: http://salesforce.stackexchange.com/questions/14771/internal-server-error-accessing-org-default-custom-setting-in-test-method-prob
lifewithryanlifewithryan
I guess misery loves company. I think we've found a bug :) (Actually smiling a little, is that bad?)