One of the most popular questions we get regarding Currency fields is: "Where is the currency actually stored?" Please don't pull your hair out when I say this, but, it depends on the Currency Model being used. "What!" Okay, okay, please don't hurt me.
There's actually two, yes two, field types that fall into this area: Currency and Price. The Price field type is actually an extension of the Currency field type and, can you guess what the biggest consumer of the Price field is? If you answered Service Catalog, you deserve a treat so go ahead and enjoy the moment. I'm not going to dive into the workings of the Service Catalog and the Price field as that was already covered nicely by suzanne.smith in Customizing prices and currency in your Service Catalog.
What I will do, over a two part blog, is show you what happens behind the curtains.
Currency models tell the platform how it will work with currencies. There are two currency models:
- Multiple Currency Model (We're going to focus on this one in this post)
- Single Currency Model
The Multi Currency Model referenced in the product documentation is specific to the Service Catalog, so let me help you dodge a bullet. Leave it . This is because you are not presented with creating a number of fixed currency prices when using the Currency field type, that's with the Price field type. Let's dive in and look at each currency model.
Using a Multiple Currency Model
Under a multiple currency model, you specify a fixed price based on locale. The Instance is configured to use this straight out-of-the-box. What this does is give the user to select the desired currency symbol in a drop-down when entering a value in the field.
(Euros please)
Where do those currency price symbols come from? These are pulled from the active records in the Currencies [fx_currency] table. So go ahead, navigate to that table, activate and de-activate some records, and see what happens with the drop-down.
So, of course, referring to the screenshot above, the value of 1997.98 will be stored in the database. But, how does it know what the currency symbol is as that is not stored in the record? This is where the Currency Instances [fx_currency_instance] table comes in. The currency symbol and the value is stored into this table. Specifically these are "mapped" into the currency (fx_currency_instance.currency) and amount (fx_currency_instance.amount) fields.
There are also three other fields on the Currency Instances table so we know where these currency values come from:
- Table - where the originating record is
- ID - sys_id of the originating record
- Field - that currency field on the originating record we are interested in
For example here's what this looks like in action: It shows how the values of the Cost field for this Hardware asset is being mapped to a record in the Currency Instances table. So let's talk about something new that just cropped up from this - the Reference amount and Reference currency fields. Referring to the screenshot above as an example, the user entry for the Cost field is €1,997.98, but my Instance's locale is (by default) empty. When empty that means the Instance is using en.US as its base location. In which case the base currency for my Instance is in Dollars ($ USD). When the currency and amount were inserted into the Currency Instances table, a conversion took place so that we have the converted amount and currency symbol in the Reference amount and Reference currency fields for Dollars. |
The locale is set using the glide.system.locale property. You will see the property when navigating to System Properties > System Localization.
On that note, as it is more of a warning than a "just so you know, by the way," we got to the end of this model, phew. Stay tuned for Part 2 coming soon!
6 Comments
