Just because a piece of data appears as say, a currency on screen when in your xplan site, doesn’t mean the data is actually stored that way.
There are many examples throughout xplan where this is the case, with the most common being: portfolio data, risk researcher and wealthsolver, all storing data in ways which will require you to floatify so you can manipulate them into the format you want or even perform xmath and calculations with them.
It’s worth noting that some elements contain methods to get a floating point values naively:
‘Unformatted’ and ‘Raw’ data from portfolio report sources and XTOOLS paths should be floating points natively.
Currency items can natively be converted by adding .value to them. For example $client.total_assets.value would work in the currency function from earlier without needing to floatify it.
Follow up questions
Some further questions you might have and answers to them.
Isn’t this what float() is for?
Yes float is used and helpful in converting numbers to be floating points but you cannot ‘float’ datatypes that are not native numbers.
For example, you can’t float the mystring variable used above, you need floatify to correctly strip out the additional data and convert it to a floating point.
If Floatify is really built in as you “claim”…why is <:let floatify…:> defined in my templates?
Great observation and question.
In essence it’s not needed anymore. At best it’s depreciated coding that’s just taking up space. At worst, there’s always the possibility eventually it could interfere with elements of standard functioning.
Why is it still in the templates then?
As we mentioned earlier there was a time when it was needed because floatify was not part of the standard compiler – it wasn’t built in (unlike now).
It keeps appearing in templates because it’s a piece of legacy coding that likely has no impact and also since a lot of people don’t understand what it does, it just keeps being included – rather than removed.
Case in point is the IRESS Risk Researcher template via the template library. Floatify is unnecessarily defined multiple times in the remuneration section. There are other examples of depreciated coding that appear in standard templates, this is one of them and we will get to the others through subsequent articles.
Matthew is an experienced and innovative Xplan consultant and developer, having worked on and developed some of the largest advice projects in the industry. Passionate about building great experiences in xplan that enable businesses and clients to get the most out of this powerful software.
Another example of a key function that often gets used. Here we build up on our previous work with sentence syntax and join() function to see how it can deliver on less code, consistency and ease of readability.
Risk Protection is a cornerstone of wealth management and being able to xmerge everything related to them is key for efficient advice documents, fact finds, renewal notices and policy schedules. This page is the bible of existing insurance xmerge coding.