Addresses - Quite a challenge

Working on a project for a client. A project team full of engineers. Engineers licensed to validate documented procedures, point out faulty software and abnormalities. Delicious when Microsoft CRM 2011 is to be delivered under the pseudonym xRM.

Fortunately, Microsoft a large international company that develops software for small, mid-and enterprice customers .......

And so I find myself again - facing issues related to addresses.

The task is to implement files with the underlying cases. And integrate this to an ERP solution using SCRIBE and SSIS. On each Account, File and Case it is required to have:

• Owning customer (with associated addresses and contacts)
• Requesting customer (with associated addresses and contacts)
• Invoice account (with associated addresses and contacts)

No problems.

Even though the ownership of a set of address information must be respected for each of the 7 departments that are present in the company.

Ok - it's ironic. And yet not - the solution has been to use addresses as they are intended to be used, with a relationship to the Business Unit and an additional type of addresses depending on use. (Needed a second dimension in addition to the built in address types). A custom form to select and filter for the addresses that are relevant to file and cases based on the at the account suggested starting points.

But sad, due to the fact that addresses in relation to accounts and contacts are fixed in terms of how to be modified and used from these two main entities.

Address 1 and 2 are listed on both the Account and Contact. But whether it is one or the other is not thought through. (Sorry M $ - But it's not ....) It seems like a reminisæns from 1.2 and 3.0, which is on the list of functionality to be optimized at a time.

The problem arises when you save a record for the first time. A related record is created a  Address Entity if you have entered information in the Address 1 field from the main entity. And an additional record if you specify information in the Address 2 fields on the same main entity.

As this solution for the client must have a certain level of usability and at the same time is integrated with an ERP system that have similar flaws as MS CRM, creating a custom address entity, add the extra fields to address the entity required and the custom form is a must. A de normalization of the construct from the system address entity, gave a few additional enhancements for use in general.

Try playing around with the account, contact and address entities to discover the odd behavior, some one decided should be the way to deal with addresses. 

One day in the future ......

Thought that crossed my mind when i get: Either the file could not be uploaded, or this is not a valid Customization file

From time to time i have experienced that importing customizations from one Microsoft Dynamics CRM 4.0 environment to another like from live to development, might cause problems.
For a long time i have been convinced that the issue were caused by missing RoolUps, moving accross native language for CRM installation.
Now, all blogposts i have found on this issue has different approaches to solving the issue. Some has success by increasing filesizelimit in web.config. Others clean up attributes that with no reasonable explanation are missing in schema but still represented on form objects or in views throughout the application. Others again faces oconflict between versions of Rollups.
Latest i read this thread.

Well, now i am convinced that the issue is far more simple than that.

Removing any tags from exported xml file regarding custom entities that define any custom icons make all my previous attempts on different organizations work!

So xml file is just a noline textstring seperated with tags. could it be that that string is missread by the parser on import, and that the mistake is that it is limited by the lenght of some types of tags?

Hope that this will be solved in a future roolup for Microsoft Dynamics CRM 4.0.