tracking code
LBMC Technology Solutions
  • Home
  • Solutions
    • Dynamics 365
    • Dynamics NAV
    • Dynamics GP
    • Dynamics CRM
    • Sage Intacct
    • Document Management (ECM)
    • Network Engineering and IT Solutions >
      • IT Security
      • Managed IT
      • Business Phone Systems
  • Events
    • All Upcoming Events
    • Training / CPE
    • Webinars and Workshops
  • Resources
    • Blog
    • Forum
    • On-Demand Webinars
    • Referral Program
    • Services We Offer
    • Support
  • About Us
    • Careers
    • Partner with Us
    • Community
    • Contact Us

10 little-known functionalities of calculated fields in CRM 2015

12/5/2014

 
Posted by Paul Haag

Previously to Microsoft Dynamics CRM 2015, your only option to create a calculated field was to either create a plugin or JavaScript to perform the calculation. If you wanted to support immediate feedback when the user changed one of the dependencies in the front-end as well as calculation on imports, you often had to do both.
Request your free CRM check-up

New in Microsoft Dynamics CRM 2015

With CRM 2015, however, calculated fields can be added through the standard field editor. With standard availability for CRM 2015 now upon us, we’ve had a chance to play around with the real-world behavior of this new field type.

Using the editor to create calculated fields

The actual use of the editor to create the fields is fairly straightforward and no doubt will be documented adequately elsewhere, so I’m not going to go into that.

Lesser-known functionality

Instead, I’ve tried to detail some of the non-obvious functionality below.
  • The formula editor assists with entering valid fields with type-ahead for field names (“Intellisense”). These fields are not filtered by type. For example, if you are creating a currency rollup field, text fields will appear in the list, but if you attempt to use one of them improperly, you will get an error message telling you that you can’t save the current definition.
  • Using Intellisense results in the selected field being added at the end, not where the cursor was.
  • Creating a calculated field appears to immediately set the value for all records.
  • Calculated field values are persisted to the [entityname]Base table.
  • If any of the fields included in the calculation are null, the calculated value will also be null. Unfortunately, there doesn’t appear to be a function to supply a default value to avoid that case, so it will either need to handled for the dependent fields themselves or with an exponentially increasing (for each dependent field) set of conditional statements within the formula.
  • Using a decimal field within a whole-number calculated field results in the decimal value being rounded rather than truncated. The rounding occurs on the final value, rather than on each individual decimal field. So, 12.34 * 25 = round(12.34 * 5) = 309 instead of round(12.34) * 25 = 300.
  • The division operator is a forward slash (/) not a backslash (\) and the multiplication operator is an asterisk (*) not an x. The string literal character is a double quote (“), not a single quote (‘). Modulo (percent symbol) and power (carat) operators don’t appear to be supported, but grouping mathematical operations with parentheses is.
  • You can include decimal or whole number, but not date, fields in calculated string fields, but I couldn’t figure out how to control the formatting. If you use the field value directly, the decimal value is included without the currency symbol and with the precision defined by the source field (e.g. a calculated field that is CONCAT(“Total Revenue is “, totalrevenue) will show something like, “Total Revenue is 37.34”). However, if you perform a mathematical operation on the numeric field, it shows 10 decimal places (so, if totalrevenue is divided by 2 in the formula above, the result is, “Total Revenue is 18.6700000000”).
  • When creating a formula for a single line of text calculated field, single line of text fields with their maximum length set to the field maximum (e.g. 4,000) cannot be used. However, if you change the max length to 3,999, add it to a formula and then change its length back to 4,000, the system will use it in calculations, with anything past 4,000 characters in the result being truncated. When you open the formula again, you will get an error at the top saying too-long field doesn’t exist.
  • Not a surprise, but you cannot delete a field that is referenced in a calculation, even if it isn’t used anywhere else in the system (e.g. forms, views, etc.). This is definitely nice, since there is no such check when you are writing a plugin.

InterDyn Artis is a Microsoft partner located in Charlotte, NC. We specialize in ERP and CRM solutions, and offer implementation, customization, and support services for Microsoft Dynamics.

Comments are closed.


    Blog

    ​Your one stop shop for technology.

    Categories

    All
    Business Central
    Dynamics 365
    Dynamics CRM
    Dynamics GP
    Dynamics NAV
    Events
    Microsoft Dynamics Add-ons
    Software Decisions
    Tutorial

Solutions
Microsoft Dynamics 365
    Business Central
    Customer Engagement
Microsoft Dynamics NAV
Microsoft Dynamics GP
​Microsoft Dynamics CRM
​Sage Intacct
​
Network Engineering

​ERP Comparison Guide
Learning Opportunities
All Upcoming Events
User Conferences
Training / CPE
Vision
Webinars & Workshops
​

Resources
Blog
Forum
Referral Program
​​YouTube Channel

Company
About Us
Careers
Contact Us
​
Locations
Charlotte
Knoxville
Nashville
Picture
Picture
Proudly powered by Weebly

Sitemap | Home | Careers | Contact Us

share

Copyright © 2019

LBMC Technology Solutions