Unitek Microsoft CRM Blog

If you’re a Microsoft CRM Consultant and ever needed to work with Microsoft Excel for cleansing data you’ve probably encountered the unwanted formatting of certain characters like leading and trailing spaces, and more to the point, leading zeros. Of course any Office guru can remind you about the ‘special’ formatting on cells in excel like ‘zip code,’ but what if your experience in excel is just one stop in your data cleansing experience, and you don’t plan on using excel as the data source?

If you’re using Scribe as an ERP migration/integration tool like Unitek Consulting does, you’re probably in the habit of opening the .csv file to make sure your formatting kept the leading zeros on your zip codes intact – but of course excel does not store cell formatting changes in .csv files so you won’t see your leading zeros.

So let’s say you don’t open that .csv file, and use it as a source for your Scribe import (Scribe has an Excel Driver, but you can’t run SQL queries for your pre-operation step controls or data translations) without opening the file in Excel – you STILL don’t see your leading zero!
The problem there exists when your ODBC driver fails to capture the leading zero because it would rather see a VARCHAR field…
Solution:

Force Scribe to read your zip code fields that only have 4 characters by using the following formula expression:

IF( LEN( S1 ) < 5, SUBSTITUTE( PAD( S1, “R”, 5), ” “, “0″), S1 )

Where S1 is your zip code source field.

Please note that this is only one of several solutions, but if you are in the Scribe Workbench you can avoid lots of data cleanup in various other applications.

For more information about working with .csv files converted from Excel, please visit: Creativyst Docs.

Happy Migrating!!

MM
Microsoft CRM Consultant
Unitek Microsoft CRM Services

At Unitek, we cover the full gamut of Microsoft Dynamics CRM 3.0 and CRM 4.0

• CRM 3.0 & 4.0 Training
• CRM 3.0 & 4.0 Consulting
• and CRM 3.0 & 4.0 Everything Else…

For today’s blog, I would like to share with you a story from a recent discussion I had with one of our clients using Microsoft Dynamics CRM 3.0. They were having some difficulties setting up a QUEUE in Microsoft CRM 3.0 and were stuck in the process. They were doing everything right, step-by-step, but were missing a major part in the process and maybe there are some of you out there that are experiencing the same thing?

So, everyone say it with me… the first step is… Create the user. Simple process, just make sure you set the correct privileges and attributes.

If you’re using the CRM implementation guide, you’ll notice that they require you to DISABLE the user account. There is still some question in the greater CRM community as to whether or not it’s a required step; but do as Microsoft says here… disable the user account.

Next step? Add the queue into the CRM Application.

And this next step is where the struggles started for my client. After sending out a test email to the queue, they saw that nothing happened. They had reviewed the event logs on both Exchange and CRM servers, but there was nothing listed. They tried working with user privileges and registry keys, but to no avail. Because they had restarted the Exchange Router, IIS, and Exchange Server itself (Several times), the system admin got pretty upset because MOM (Operations Manager) was driving him up the wall with alert messages.

What step did they forget? Believe me, it’s an easy step to remember… You have to add mailbox rules to the user of the queue. Using the rule deployment wizard for this step. It’s that simple. Once the rule deployment wizard is finished, you can send out a sample email to test. If these steps were completed, you’ll see the email appear in the QUEUE you just created. Congrats! You’re now ready to go onto the next issue.

JH
Microsoft CRM Consultant
Unitek Microsoft CRM Services

Hello fellow Microsoft CRM 4.0’ers – today’s blog entry involves an issue that at least 3 implementations that I’m aware of are suffering. This issue sometimes appears when you import customizations and subsequently attempt to change the default public view for that entity.

In this scenario, I’ve renamed the “Accounts” entity to “Company” (a common customization) and according to the business requirements I attempted to change the default public view to “Active Companies.”

When this is completed we see two default public views for this entity: Continue Reading »

It happens often that you would want to access/update fields of other entities using jscript from either OnLoad, OnSave or OnChnage events. Here I am using SOAP calls to make this happen.

As a CRM consultant, recently I had to do a project that required using a read, check and update SOAP calls. I will provide a very simplified version of this project for this blog entry.

Scenario:
Company X sells widgets and not only they want to keep track of who they sell these widgets to but also they want Microsoft CRM to automatically generate a Serial Number each time they create a new widgets record. To keep it simple, we will use a simple Serial number format: WID1000 would be the first Serial number; WID1001 would be the second, WID1002 the third and so on.

Created a new custom entity named “Widget”. Related it to Account entity with a Parental relationship (Account being the parent). Created an attribute for the Widget entity and named it WidgetSerialNum.

Created a new custom entity called Counter to hold the next available counter value. Added three attributes to this entity:

1. “ItemType” to hold the type of the item we would want to create serial numbers for. In this scenario there is only one; Widget. The value is “Widget”
2. Prefix set to “WID” to hold the Prefix for the serial number
3. Countervalue set to 1000 to hold the next available counter value

Placed the following Code in the OnSave event of the Widget entity. All the instructions are part of the comments so you can just cut and past the code.

Continue Reading »

Unitek’s Microsoft CRM Practice not only specializes in CRM Certifications, but also has a large force related to CRM 3.0 & 4.0 Consulting Services. With that in mind, I’d like to talk a little bit about some of the issues that we have seen with other clients and the following topics will specifically address the Mail Merge Wizard within Microsoft CRM 4.0.

Microsoft Dynamics CRM 3.0 Mail Merge was created to work only with Accounts, Contacts, and Quotes. The overall functionality was there, but the tool had some limitations and complications that Microsoft obviously felt needed to be changed.

• It did not allowing the user to easily create email templates or other letters, faxes, documents.
• It did not support Mail Merge for the Web Client.
• It did not support Quick Campaigns.

Just a few of the improvements made to the Microsoft CRM 4.0 Mail Merge tool includes:

• Automatic upload of templates from MS WORD. (all versions) MS WORD 2007 even includes a section dedicated to CRM Mail Merge E-mail templates!
• The ability to run with both the Outlook and Web Clients.
• The creation of Activities associated with the Mail Merge and upon completion, the listing of those completed activities in the History view.
• The ability to run Mail Merges for Quick Campaigns, which is very helpful for those quick email blasts and newsletter distributions.

Continue Reading »