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 ......