gustafwesterlund: Address management

[Blog bot]

Источник: http://gustafwesterlund.blogspot.com...anagement.html
==============

As I have been around to a couple of different companies using CRM, some of which have been implemented before I started working with them and some I have been with from the start there are some things that can be said of the address management in CRM 2011. My general recommendation being to not use it as it is but to do some minor changes to make it work for you.

To start off, I would like to go into some detail of how the address handling is actually done in CRM.

There is, as you probably have seen, a field with the default display name "Address Name". This can be hard for normal users to understand without instructive training. What it should be used for is to specify what the name of the address or that customer is as an internal name for that address, like "Main office in Berlin". Due to the ambiguity of the field, I have seen different ways of putting data into it, one is repeating the company name, where the notion is that it is to be the first row of the address when mailing, in essence being the "name to which the address is going". This field is also a requirement for some logic in CRM, in particular the different address lookups you can find for instance in the Order or Contract. For an address to show up in this lookup it has to have an "Address name". This is also the main selection data in this lookup (by default anyway), why a descriptive name is useful, for instance "Main office in Berlin" and "Postal address".

So, why this requirement on address name, you might wonder? Well, behind the scenes this logic is a bit more complicated. When entering an address into address1 or address2 in an account or contact, it will actually sync this to a replicated instance of the customeraddress entity in the background (created when the account/contact is created, with addressnumber 1 and 2). This is the same entity that you are looking at when looking at the "More addresses" in the contextual navigation menu within account or contact. CRM then maintains sync between the data in the account/contact and the customeraddress. These two customeraddresses are, however, filtered out from the list shown in "More addresses" but you will find them if you check the SDK or the database.

Hence there is need for some good data in the field "Address Names" so that it can be used in the lookups but it is also hard to intuitivly understand what to put into this field with the current caption.

Hence my general recommendaton for this field would be to either change its caption so that it is more instructive or have some automated logic set it by default.

An interesting fact is that the no address names field have been set by in the sample data provided by Microsoft that can be installed from within CRM. So if you want to demo the address lookups, make sure to set some fitting address names first, otherwise the address lookups will be glaringly empty. Let's hope this changes soon.

The second field that is interesting is the drop down with the default display name of "Address Type". It contains several values indicating which type of address this is. I have not seen any built in logic that uses this data. As there is some very significant correlation between this drop-down field and the "address name" I would recommend either linking these with logic or removing the "Address Type" field from the form.

Which fields are used for the specific address is usually country dependent. For instance the field address1_line3 and address1_region is almost never used in Sweden but is more commonly used in countries like Germany or USA. I will not go into which field are to be used for the address due to this reason. My general recommendation being to keep it as simple as possible. For multi-country implementations, try finding the lowest common denominator.

An additional interesting point is the Outlook syncronization of contacts. This syncronization will use the first address and as the address in Outlook for a contact, is syncronzed to the back-end mail server (usually Exchange) and then on to the Windows Phone (or similar inferior device). From the phone, the most usable address is the visiting address, as that is usually what you are looking for when you are checking the contact in you phone. There is also a default mapping of address1 in account to address1 in contact for contacts created from the account. Based on this, I generally recommend defining address1 as the Visiting address for both account and contact as this will harmonize best with the mobile way of using this data.

As for different ways of implementing the logic, I have seen a couple of different ways.

The first version that you will encounter is the standard way of handling addresses based on the logic of the field described above. This will in general confuse the users with the two fields with correlated information without logic to tie them together, the other is what I mentioned above, that the ambiguity of the caption "Address name" makes things confusion. The fact that the address type field also exists on both addresses, especially on address one, means that contacts created from an account will with the default mapping have different address types showing up in Outlook and in the mobile devices. And I for one, do not believe that the invoice address is all that interesting to have in the mobile device. I would not recommend using it without some customizations.

There is also a problem with using the "Address Type" field as this will mean that there is no simple way of knowing which address is the postal address, the address type always has to be checked. This really complicates things when doing integrations to other systems as well, as they usually don't work this way. It also makes analysis based on this data more complex, and in particular makes it too complex for normal users trying to do some ad-hoc reporting with charts, advanced find and excel.

Another way of using addresses that I have seen is to change the caption of address1_line1 to be "Postal Address" and then address1_line2 to be "Visiting Address". Some of the people I have discussed this with like it because it makes life easier for them (they don't have to enter two addresses). This means that the other fields will be shared between the two addresses like the field "address1_city". They also argue that for most customers these are the same. However, for group of customers, usually larger, that have different visiting and postal addresses also on a city level, this makes things problematic as it is very useful to have the City also on the visiting address, for instance when navigating to the customer with a GPS, and you don't want to be stuck at a PO-box.

This way of sharing data for different addresses with an address in CRM will also break the logic described above with the address lookups in for instance Order and Contract. The address name has to be set to "Postal Address" and there will be no way of for instance setting the delivery address of an order to the "Visiting Address". As for the argument of it being easier, that can be solved with a couple of lines of javascript code that default the data from address1 to address2 if it is empty.

The way I like to set the address management up in CRM starts of by defining the two addresses to usually Visting address for address1 and Postal address for address2 for both account and contact.

I trim the address fields and remove the address type field.

Next I create a javascript that sets the "Address name" fields to "Visiting Address" and "Postal Address" and then disables and force submits the fields.

In some cases I also create an additional script that will copy the address from address1 to address2 if the latter is empty.

I try to make sure that the address fields in Account, Contact, Customer Address, Quote, Order, Invoice, Contract and related entities are similar.

As an extra note, for the Swedish market, we, at CRM-Konsulterna, have created a small ISV-solution available on the marketplace that does this. Please read more about it here (Swedish): http://www.crmkonsulterna.se/Pages/S...npassning.aspx

As there are no rights or wrongs in this subject, please feel free to leave a comment. I would encourage a discussion on the subject.

Gustaf Westerlund
MVP, CEO and owner at CRM-konsulterna AB
www.crmkonsulterna.se

Источник: http://gustafwesterlund.blogspot.com...anagement.html

[Blog bot]

Источник: http://gustafwesterlund.blogspot.com...anagement.html
==============

As I have been around to a couple of different companies using CRM, some of which have been implemented before I started working with them and some I have been with from the start there are some things that can be said of the address management in CRM 2011. My general recommendation being to not use it as it is but to do some minor changes to make it work for you.

To start off, I would like to go into some detail of how the address handling is actually done in CRM.

There is, as you probably have seen, a field with the default display name "Address Name". This can be hard for normal users to understand without instructive training. What it should be used for is to specify what the name of the address or that customer is as an internal name for that address, like "Main office in Berlin". Due to the ambiguity of the field, I have seen different ways of putting data into it, one is repeating the company name, where the notion is that it is to be the first row of the address when mailing, in essence being the "name to which the address is going". This field is also a requirement for some logic in CRM, in particular the different address lookups you can find for instance in the Order or Contract. For an address to show up in this lookup it has to have an "Address name". This is also the main selection data in this lookup (by default anyway), why a descriptive name is useful, for instance "Main office in Berlin" and "Postal address".

So, why this requirement on address name, you might wonder? Well, behind the scenes this logic is a bit more complicated. When entering an address into address1 or address2 in an account or contact, it will actually sync this to a replicated instance of the customeraddress entity in the background (created when the account/contact is created, with addressnumber 1 and 2). This is the same entity that you are looking at when looking at the "More addresses" in the contextual navigation menu within account or contact. CRM then maintains sync between the data in the account/contact and the customeraddress. These two customeraddresses are, however, filtered out from the list shown in "More addresses" but you will find them if you check the SDK or the database.

Hence there is need for some good data in the field "Address Names" so that it can be used in the lookups but it is also hard to intuitivly understand what to put into this field with the current caption.

Hence my general recommendaton for this field would be to either change its caption so that it is more instructive or have some automated logic set it by default.

An interesting fact is that the no address names field have been set by in the sample data provided by Microsoft that can be installed from within CRM. So if you want to demo the address lookups, make sure to set some fitting address names first, otherwise the address lookups will be glaringly empty. Let's hope this changes soon.

The second field that is interesting is the drop down with the default display name of "Address Type". It contains several values indicating which type of address this is. I have not seen any built in logic that uses this data. As there is some very significant correlation between this drop-down field and the "address name" I would recommend either linking these with logic or removing the "Address Type" field from the form.

Which fields are used for the specific address is usually country dependent. For instance the field address1_line3 and address1_region is almost never used in Sweden but is more commonly used in countries like Germany or USA. I will not go into which field are to be used for the address due to this reason. My general recommendation being to keep it as simple as possible. For multi-country implementations, try finding the lowest common denominator.

An additional interesting point is the Outlook syncronization of contacts. This syncronization will use the first address and as the address in Outlook for a contact, is syncronzed to the back-end mail server (usually Exchange) and then on to the Windows Phone (or similar inferior device). From the phone, the most usable address is the visiting address, as that is usually what you are looking for when you are checking the contact in you phone. There is also a default mapping of address1 in account to address1 in contact for contacts created from the account. Based on this, I generally recommend defining address1 as the Visiting address for both account and contact as this will harmonize best with the mobile way of using this data.

As for different ways of implementing the logic, I have seen a couple of different ways.

The first version that you will encounter is the standard way of handling addresses based on the logic of the field described above. This will in general confuse the users with the two fields with correlated information without logic to tie them together, the other is what I mentioned above, that the ambiguity of the caption "Address name" makes things confusion. The fact that the address type field also exists on both addresses, especially on address one, means that contacts created from an account will with the default mapping have different address types showing up in Outlook and in the mobile devices. And I for one, do not believe that the invoice address is all that interesting to have in the mobile device. I would not recommend using it without some customizations.

There is also a problem with using the "Address Type" field as this will mean that there is no simple way of knowing which address is the postal address, the address type always has to be checked. This really complicates things when doing integrations to other systems as well, as they usually don't work this way. It also makes analysis based on this data more complex, and in particular makes it too complex for normal users trying to do some ad-hoc reporting with charts, advanced find and excel.

Another way of using addresses that I have seen is to change the caption of address1_line1 to be "Postal Address" and then address1_line2 to be "Visiting Address". Some of the people I have discussed this with like it because it makes life easier for them (they don't have to enter two addresses). This means that the other fields will be shared between the two addresses like the field "address1_city". They also argue that for most customers these are the same. However, for group of customers, usually larger, that have different visiting and postal addresses also on a city level, this makes things problematic as it is very useful to have the City also on the visiting address, for instance when navigating to the customer with a GPS, and you don't want to be stuck at a PO-box.

This way of sharing data for different addresses with an address in CRM will also break the logic described above with the address lookups in for instance Order and Contract. The address name has to be set to "Postal Address" and there will be no way of for instance setting the delivery address of an order to the "Visiting Address". As for the argument of it being easier, that can be solved with a couple of lines of javascript code that default the data from address1 to address2 if it is empty.

The way I like to set the address management up in CRM starts of by defining the two addresses to usually Visting address for address1 and Postal address for address2 for both account and contact.

I trim the address fields and remove the address type field.

Next I create a javascript that sets the "Address name" fields to "Visiting Address" and "Postal Address" and then disables and force submits the fields.

In some cases I also create an additional script that will copy the address from address1 to address2 if the latter is empty.

I try to make sure that the address fields in Account, Contact, Customer Address, Quote, Order, Invoice, Contract and related entities are similar.

As an extra note, for the Swedish market, we, at CRM-Konsulterna, have created a small ISV-solution available on the marketplace that does this. Please read more about it here (Swedish): http://www.crmkonsulterna.se/Pages/S...npassning.aspx

As there are no rights or wrongs in this subject, please feel free to leave a comment. I would encourage a discussion on the subject.

Gustaf Westerlund
MVP, CEO and owner at CRM-konsulterna AB
www.crmkonsulterna.se

Источник: http://gustafwesterlund.blogspot.com...anagement.html