Showing posts with label CRM. Show all posts
Showing posts with label CRM. Show all posts

Wednesday, February 27, 2019

What is the solution version number used for?

A recent thread of discussion on the CRMUG forums about this topic got me thinking – here is my take on the subject.

For the smaller clients with no integration, I think there is value in using the current date in the solution version number so when you export it so that you can easily keep track of which file in your downloads folder is the right one. A quick acknowledgement to @Gus Gonzalez's for making that suggestion. End users can easily comprehend it and it adds value to them. A solution file can have literally anything in it and the (typical) version number does nothing to help you with figuring out what is major/minor/patch or resolving dependencies. By using Gus's technique, the date of the solution is built into the exported file name. By using Gus's technique, you avoid having multiple copies of a file called "SolutionName_1_0_0_0.zip" and trying to figure out which one is relevant. I would argue that for the people creating solutions for small(er) organizations, it is not easy to make the distinction of major vs minor. Can anyone here define how many fields on a form must move before you cross the threshold from a patch to a minor release, or how many business rules must be changed before it becomes a major release?


But for a company that has a staff of developers that depend on integration with other systems and have governance policies, we should consider the benefits to the version number with a traditional approach. For many of my past projects, I have clearly agreed with @Ben Bartle's position because I come at this as a developer. The reason has to do with traditional software development practices: When writing applications that have dependencies on a multitude of libraries (.DLL's), then keeping track of the version number helps you identify whether an update to a library will significantly impact your application. With a DLL it is easy to define what is major, minor or a patch based on best practices.

For a consultant that is configuring systems for many clients, I would recommend that you have the name of the client for the solution name, and put the D365 version in the first two decimal positions of the version number, and date in YYMM.DD format in the last two positions. This makes it easy to tell which version of D365 you exported the solution from (which could be significant if the development area is not in sync with staging and production) and the date it was exported.

To bring this point back into context of this discussion, when you modify a D365 solution and then promote it to production, you are actually updating the API endpoints. Consider what happens when you alter the behavior of workflows, deprecate entities/fields, or make the field length shorter. When you promote that solution into production, you run the risk that integration code will break.

Personally, I have been putting the date in the solution's Information/Description field.  While this is not as pretty as using the version number as a proxy for a date, it serves it purpose because you can see the solution description gets updated in the production system. The only downside with that approach is that you have to either import the solution file to see the description containing the date, or rip apart the zipped solution file and read the XML files.

With respect to keeping track of whether the solution file contains a major/minor/patch to a system, that is something everyone should be documenting anyway regardless of whether you go with Gus or Ben's recommendation. By keeping a log of changes and/or implementing a full version control system between development/staging/production, you must be communicating your changes to your testing staff or your end users, no matter how small the change is. If users detect a change that you were not in control of, they might think the system is unstable, and they will lose confidence in your system.

Wednesday, July 11, 2018

How To set up your fiscal year in Dynamics 365

Why you would do this:
For clients that have a fiscal year that starts on January 1st, the system default is already set and you don't need to do anything else at this point. However, some of my clients have a fiscal year that starts on a different month, and this article is for them. Setting up the fiscal year allows you to use features in your views and sales goals based on the fiscal year, for example
image
To set your fiscal year: You need to have System Administrator rights to access this feature. If you do, then navigate to Settings/Business Management/Fiscal Year Settings
clip_image002
Then update the start date to 9/1/18 or what ever the first day is of your last fiscal year (the year is not important in this date field, only the Month/Day)
clip_image004





Wednesday, June 27, 2018

Too much whitespace on Dynamics 365 v9 forms–workaround!

I was frustrated with the amount of whitespace on the new v9 D365 CE forms so I started doing some research. Using the Chrome browsers DevTools (press F12), I was able to identify the style I wanted to modify:

TABLE.ms-crm-FormSection td

This style adds 10px of padding to the top and bottom of all form elements.

I found a nice bit of JavaScript code that uses appendChild() to insert a modified style into the Head of the document. It seemed to work…for about a day, then the form seemed to go back to the previous rendering. Having some (not much) experience with styles, I know that that styles can be affected by many things, including the order they are loaded, and I have no patience for diving in any deeper. Instead I found a nice workaround: stylebot. This is an extension to Chrome that allows me to define my own styles for any given domain. After adding the extension, navigate to CRM (or refresh your page if you are already there), then click on the “css” icon in the top-right corner and choose Open Stylebot to get here:

2018-06-27_1146

in the field that says  “Select an Element” type in

TABLE.ms-crm-FormSection td

The domain name should appear directly under it. Click the Advanced button, and enter the style code:

padding-top: 0px;
padding-bottom: 0px;

then click the “x” to close stylebot and refresh your page. Now the whitespace is gone! Hope this makes you day a bit better.

Wednesday, October 4, 2017

Find other accounts near an address

I have a customer in NYC that we are helping to implement Field Service using Dynamics 365 (online). One of their hot issues is making it easy for them to find all other accounts near a given location, so I started thinking about the problem.

One of the features built into that solution is geocoding, so that all account addresses get a geocode. If I could use SQL queries, I would be able to use a native SQL query to find all addresses near a given point. As far as I know, the FetchXML syntax does not do those kinds of queries.

To narrow down the problem space a bit, my client only works in the NYC area which makes things a bit easier because we can simplify the variables: We don't need to worry about the curvature of the Earth over long distances, or the distance between longitudes for a given latitude. I am going to simplify this a bit more. If I ignore the fact that a radius around a point is the best representation of what is nearby, and I use a rectangle which is good enough for my clients purposes, then the query is super simple because now I just need compare the current Lat/Long with ones that are between "+" or "-" a difference in order to define the rectangle.

Lets say, from a given Lat/Long, we need to know who is inside a vicinity of  1 square mile. That means we are interested in all locations that are roughly 1/2 mile North, 1/2 mile South, 1/2 mile East and 1/2 Mile West from the current point.

Each degree of latitude is 69.99 miles apart.
At 40 degrees latitude (NYC), the longitudes are 53.08 miles apart.

Therefore, 1 mile is about (keep it simple):
1/69=0.0145 degrees of latitude
1/53=0.0189 degrees of longitude

So if we search for all addresses that are within one square mile, then we are looking for a Lat/Long that fall within the range of the
current location +/- half the 1 mile area.

So if we are at this location: 40.61938 Lat, -73.91799 Long, then we are looking for all addresses where the latitude is:

40.61938-(.0145/2)=40.61213 and 40.61938+(.0145/2)=40.62663 (up to 1/2 mile South and 1/2 mile North of us)

And the longitude is:
-73.91799-(.0189/2)=-73.90854 and -73.91799+(.0189/2)=-73.92744 (up to 1/2 mile East and 1/2 mil e West of us)

and in Advanced Find, would look like this:


Remember, because NYC is in the western hemisphere, the longitude is negative.

Ultimately my goal is to take this kind of query, build it into a JavaScript on a form and populate a map with the points. But that is a blog for another day.

Sunday, August 29, 2010

MS CRM Autofilter gotcha

I am building a report using SSRS that I intend to use as an auto-filtered report inside of MS CRM (see http://blogs.msdn.com/b/crm/archive/2009/03/06/microsoft-dynamics-crm-pre-filtering-tips.aspx). The report pulls data from several views. Everything seemed to be working fine in development until I imported the report into CRM, then parts of the query seemed to stop working.

If you read the end of that article, it points out that all the entities referenced in the FROM or JOIN clauses will have a default filter applied to them that will limit what is included in the query to only records that were modified in the last 30 days.

In my case, I was using a parent entity with 4 outer joins, and I was only retrieving some of the data because some of the related tables had data that was not modified recently.

My solution to this problem was to create a single report that uses only one view with the CRMAF alias, and it used a sub-report that did not have the CRMAF alias on the views. This permitted me to associate the parent report with the entity, and pass the ID’s to the sub-report where there was no filtering.

In my case, I was creating a custom invoice for a custom invoice entity, so I created my parent report with just the one filtered view and gave it an alias of CRMAF_custominvoice. I embedded the sub-report in a table (tablix for VS 2008) control detail band, and gave the sub-report the ID value to pass as a parameter. In the sub-report, I had the rich and complex SQL that I wanted using filtered views, but not using the CRMAF alias.

Tuesday, April 22, 2008

Change multiple records in CRM the easy way

The trick to editing more than one record is to use the Edit option under the More Actions button. If you have specific records that you want to change, use the Advanced Find feature of CRM to find the ones you want, then select them on the screen (using the checkbox, or shift-click, or Ctrl-click like you would with other Windows apps) and then click on More Actions and Edit. This will give you a blank form – any field you change there will update all the _selected_ records when you hit the save button. Warning: there is no Undo feature.

The reason I underlined the word “selected” is that all your views are limited to a certain number of records, between 25 and 250, depending on your setting under CRM’s Tools/Options/General/Records per page setting. So, for example If you have 1000 records to change, you will have to hit the Next page icon in your view and select the next group of records and do the More Actions/Edit again.

Wednesday, March 5, 2008

MS CRM Horizontal scroll bar

A client contacted me to complain that one of the users needed to see all the fields in a custom opportunity view (where they had asked for a lot of extra fields to be added). After a couple rounds of emails, the IT manager wrote back and said that he realized the user had a low resolution screen (1024 x 768) and the view did not have a horizontal scroll bar.

Here were some options we came up with (assuming IE 7):

1. Use the Internet Explorer Zoom feature – when you open the CRM opportunity list, hold down the control key and roll the mouse center wheel and it will zoom in/out so that you can see more data, albeit smaller.

2. Make the width of the columns narrower – this will make them all visible, but with the font at that size, the data will be mostly hidden.

3. Get him a bigger screen and use a slightly higher resolution (like 1280 x 1024) – this should make it easy to see and give you visibility of all the fields.

4. He could use an Excel add-in tool from Prosoft Systems, and he would have visibility to all the data in all 4 business areas

5. Change the default Text Size of the browser to be "Larger" so that when the view is rendered in its IFrame, it will be too large for the window width and force IE to render a horizontal scroll bar.

Hope this helps someone! If you have any other suggestions, please share them.

Wednesday, April 25, 2007

Formatting number fields

I have been setting up many reports for a MS CRM system using SSRS and there are a multitude of places where numeric and dollar amounts are being printed. I could just use one of the standard formatting codes provided by SSRS, but then if the customer changes their settings in CRM, it will not be reflected in the custom reports.

I realized today that there is a database function (found under the Programmability/Functions/Table-valued Functions) available to me in CRM called fn_GetFormatStrings() that returns most of the number formats I would need. The function returns a single record (you query it in SSRS like it was a table) and each field contains the number formatting string. Each field is named something appropriate, such as "NumberFormat_2_Precision" and the string looks like this: "###,###,###,##0.00;-###,###,###,##0.00;0.00". So to make use of that, we have created a query in the RDL called DSNumberFormat that pulls that one record and then in the Format for that textbox, we make a reference to that using the expression
=First(Fields!NumberFormat_2_Precision,"DSNumberFormat")