Even though we touched on bits and pieces of this recipe earlier in the previous chapters, I will be presenting here a top-to-bottom approach of replacing the standard out-of-the-box Country and Province fields with lookups. This solution will allow users to select these values from pre-defined available options, and eliminate the issues resulting from typical user input errors.
For this recipe, use one of the solutions created in earlier chapters, or create a new one. Add to your solution the Account and Contact entities where we will replace the fields with lookups.
Follow the same steps on both the Account and the Contact entities. I will only describe the process once. You can follow the same process if you create a custom Address entity, or anywhere else where you need to capture address information.
The end result will be a transformation of the following field set:
To the following:
Country
, with an internal name of new_country
.Country Code
, with an internal name of new_countrycode
. Format it as text, with a maximum length of 3
. This field will hold an abbreviated version such as USA, CA, and UK.Display Sequence
, with an internal name of new_displaysequence
. Format it as a whole number, with a minimum value of 0
. I have set the maximum to 500
, but you could set it to the total number of countries, which at the time of this writing stands at 196.State
, with an internal name of new_state
.State Code
, with an internal name of new_statecode
. Format it as text, with a maximum length of 5
, or enough to capture a short name for the state. Usually for US and Canada two characters are enough.Display Sequence
, with an internal name of new_displaysequence
. Format it as a whole number, with a minimum value of 0
. Set the maximum depending on the number of provinces/states you intend to capture in the system. If unsure, set it to a value high enough for your initial phase. You can always change the maximum value at a later time.Country
, with an internal name of new_country
. Format it as type lookup, with a target record type pointing back to the Country
entity we have just created.State
, with an internal name of new_state
. Make the field type lookup, with a target record type of State (the entity we created earlier). Add this field to our form right underneath our existing State/Province field.Country
, with an internal name of new_country
. Make the field type lookup, with a target record type of Country
(the entity we created earlier). Add this field to our form.function UpdateCountry() { var _country = new Array(); _country = Xrm.Page.getAttribute("new_country").getValue(); if(_country != null) { Xrm.Page.getAttribute("address1_country").setValue(_country[0].name); } } function UpdateState() { var _state = new Array(); _state = Xrm.Page.getAttribute("new_state").getValue(); if(_state != null) { Xrm.Page.getAttribute("address1_stateorprovince").setValue(_state[0].name); } }
UpdateCountry()
function with the OnChange
event of the new country lookup we created, and the UpdateState()
function to the OnChange
event of the new State
lookup.The process I am following in this recipe is relatively simple. We are creating the related lookups, and populating the selected values into the original fields using the JavaScript functions. We could have done this without copying the values into the original fields, but the reason I chose to do so is because now I can use all the views and reports as defined out of the box, and any future upgrades or other solutions that are referencing those fields will find them also populated with the current values.
18.117.92.199