Debugging and trouble shooting of plug-ins

Post on trouble shooting using tracer.

I was thinking of summarising few facts that would be helpful in solving issues of plug-ins. In my list of suggestions, I am also giving links to other blogs that describes the steps descriptively.

1.Test whether plug-in is firing

First thing first; as a practice I always check whether my plug-in is firing before implementing lengthy logics. For that I always develop a very simple plug-in first and test whether it fires. My plug-in is just throwing an exception. For example, check below line;

throw new InvalidPluginExecutionException("Quote Pre update...fired!");

If I see the exception, I am ready to enhance the code.

2. Debug

Debugging is the next popular way of finding whether code works as expected. This consists of few basic steps to get the debugger start for your operation.

a. Make sure you copy your .pdb files along with .dll files to the specific location
    (i.e. Program Files\Microsoft Dynamics CRM\Server\bin\assembly)
b. Attach w3wp.exe to your process in VS. (attach CRMAsyncService.exe for asynchronous operations or workflows)
c. Do the relevant operation for the plug-in that jumps the debugger to your break point.

3. Remote debugging

In order to perform normal debugging you need to have the developer environment in the CRM server itself. If your problem occurs explicitly in production server you may need to do remote debugging which could be a much complex process.

Please read this post that explains how to do it;
http://weblogs.asp.net/pabloperalta/archive/2010/12/01/how-to-remote-debug-dynamics-crm-plugins-and-workflow-assemblies.aspx

4. Write into a log file

In practical world, you are not allowed to change configurations in a production server and that can stop you from remote debugging either. In that case, you can go back to basics. Writing required information to a log file. It’s a matter of adding few lines to your plug-in code. Check below suggested code;

using System.IO;

StreamWriter sw;
sw = File.CreateText(@"C:\Devspace\log\Calcs.txt"); 
try
{
 ........... 
 sw.WriteLine("Value 1 : " + value1);
 sw.WriteLine("Value 2 : " + value2);
 ...........
 ...........
}
catch (Exception e)
{
 sw.WriteLine("Exception: " + e.Message);
 throw e;
}
finally
{
 sw.Close();
}

5. Profiling (Specially for online plugins)

Trouble shooting of CRM online plug-in could be another hurdle. 

Below post explains how to accomplish it through profiling, using latest plug-in registration tool;
http://guruprasadcrm.blogspot.com.au/2011/11/how-to-debug-crm-2011-online-plugin.html

Sales process – Part 4 – Modifying calculation of quote

In previous posts we discussed how quote pricing is done in the native way and modifying them in item level (i.e. Quote Product) in Microsoft Dynamics CRM 2011. As the final stage, we will look in to the ways of modifying the grand total (i.e. Quote) if we happen to do so.

This requirement could occur mainly as below;

a) add a surcharge, administration cost or insurance
b) give discount comes within a loyalty program or discount determined by total
c) calculation of commissions/ loyalty points according to total

Consider the pricing pane of the quote form.

Three fields I put within the green squares are editable fields. Check them with their schema names and types.

Name	Schema Name	Type
Quote Discount %	discountpercentage	Decimal
Quote Discount	discountamount	Currency
Freight Amount	freightamount	Currency

These are the field that can’t be edited. For ease of explaining, I am dividing them to two different categories.

None editable – Category A -Fields derived from the quote products

Name	Schema Name	Type
Detail amount	totallineitemamount	Currency
Total Tax	totaltax	Currency

None editable – Category B – Calculated fields

Name	Schema Name	Type
Pre-Freight Amount	totalamountlessfreight	Currency
Total Amount	totalamount	Currency

Considerations for plug-in development

Obviously we need to develop our own plug-ins to enhance/modify the current calculations. Now consider my research result on plugin behaviour in this regard. When “creating” the quote, calculations are not applicable since quote product addition comes in a later stage. In fact, we are talking about update plug-in.

Also it is important to understand user actions that update plug-in would fire.  (Will call this action type for ease of referencing)

i) Opening the Quote
ii) Saving the Quote
iii) Pressing Recalculate button
iv) Adding/ Modifying/ Deleting  a quote product

Please check below table. I use word “available” to say it is available in plug-in context. When I say “retrieve” it means retrieve the current value from database using the web service.

	Update
	Pre stage	Post stage
Editable fields (of first table)	Available if changed, otherwise retrievable. Can be modified. *	Available if changed, otherwise retrievable. Can be modified.*
None editable (Both Category A and B)	Available only for Action type (iv).** Can be retrieved. Cannot modify.	Available only for Action type (iv). ** Can be retrieved. Cannot modify.

* If you modify the same entity in Update event, make sure you avoid infinite loops.
** Plug-in run by action of addition/modification/deletion of a quote product.

Revealed plug-in behaviour seems bit complex. None editable fields become available in plug-in context when update is executed by a change of a quote product.

Other exciting observation is, when I register the plug-in for pre-stage it get executed more than once depending on users actions (refer i, ii, iii, iv) . This is bit confusing and unexplained. However, this complexity keeps us away from writing codes for pre update stage.  I am happy if someone has figured out this and can share.

Good news is we don’t need to understand all these to do our modifications.  Most important behaviour is whenever we change the editable fields, calculations get updated accordingly, regardless of when you change.

As a summery we will stick in to some rules which will give us enough space for our work. Consider below facts;

Some points to think

1) Register your plug-in in post Update.

2) You can retrieve none editable category (A) fields and use for your logic. If you see carefully, you will realise these (sum of line item values and sum of taxes) are the important reference fields to implement any logic together with editable fields.  Anyway, never try to modify category (A) fields.

3) Never try to reference or modify category (B) fields. If you want to reference them determine the values by calculating. (Reference 2nd part of this article)

4) Out of three editable fields, quote discount and freight amount gives you the most needed space to enhance the functionality as you wish. One field is being added to the total while one is being subtracted. So whatever the adjustment you need to do can be done through these two fields. Think a bit.

5) Whatever the modifications you do, you have to be creative enough to use the native total fields and native functionalities. Our changes should be carefully pushed into the bult-in mechanism through given spaces.

1st part of this article: Sales process – Part 1 – Product Catalog
2nd part of this article: Sales process – Part 2 – Quoting
3rd part of this article: Sales process – Part 3 – Modifying calculation of quote product

Sales process – Part 3 – Modifying calculation of quote product

A couple of previous posts explained the standard way of working with quotations and its level of flexibility. In rare cases, it could need you to modify the standard calculations. In this article, we will analyse options and constrains of doing such tasks in Quote product. Most popular requirement that would come your way could be implementing automated tax (or GST) system. Natively TAX is just an editable field in quote product.

Consider the pricing pane of the quote product form.

Three fields I put within the green squares are editable fields. These are the editable fields with their schema names and types.

Name	Schema Name	Type
Quantity	quantity	Decimal
Manual Discount	manualdiscountamount	Currency
Tax	tax	Currency

These are the field that can’t be edited with their schema names and types.

Name	Schema Name	Type
Price per unit	priceperunit	Currency
Volume Discount	volumediscountamount	Currency
Amount	baseamount	Currency
Extended Amount	extendedamount	Currency

Considerations for plug-in development

Obviously we need to develop our own plug-ins to enhance/modify the current calculations. Now consider my research result on plugin behaviour in this regard.

	Create		Update
	Pre stage	Post stage	Pre stage	Post stage
Editable fields (of first table)	Available, can modify	Available, can modify	Modified field available and others can be retrieved, can modify *	Modified field available and others can be retrieved, can modify*
Other field (of second table)	Not available, cannot modify	Not available, cannot modify	Can be retrieved, cannot modify.	Can be retrieved, cannot modify.

* If you modify the same entity in Update event make sure you avoid infinite loops.

Essence of this result is we can only play around with Quantity, Manual Discount and Tax. Good news is any time you change those fields; calculations are done accordingly to newly changed values of those fields. In other terms “Extended amount” get the correct value regardless of where you change those fields.

It implies CRM does its own calculations after the plug-in engine has completed its performances. In fact, you should not/ cannot amend other fields such as Price per Unit, Volume Discount, Amount and Extended Amount.

Some points to think

1) If you want to introduce an auto tax calculation method, it’s possible. Better have the logic for both create and modify event plug-ins.

2) If you consider the fact that we have two fields (namely Tax and Manual discount) to play around; tax is being added and Manual discount is being subtracted from total automatically. So whatever the additions and subtractions you need can be pushed to the current calculation mechanism if you are creative enough. Think a bit.

3) There is a chance your logic needs fields which are unavailable in plug-in context such as Price per Unit, Volume Discount and Amount. In that case, you are still able to retrieve first two fields from Price List and Discount List entities respectively and Calculate Amount. Read my 1st and 2nd parts of this article for better understanding.

4) One would also think of give up the native total fields and introduce new custom fields, WHICH IS NOT RECOMMONDED AT ALL. This means you are rewriting your own calculation logic for entire quoting including quote product and quote. That will also push you to introduce your own recalculation button in Quote header. Also you are again facing problems when quote values are transferred to Order entity in a later stage. Personally, I don’t see any reason to go in to this mess.

1st part of this article: Sales process – Part 1 – Product Catalog
2nd part of this article: Sales process – Part 2 – Quoting
4th part of this article: Sales process – Part 4 – Modifying calculation of quote

Sales process – Part 2 – Quoting

(It is highly recommended to read the first part of this article before proceed.)

In Microsoft Dyanmics CRM, Quote products are the line items under the Quote. Each Quote Product represents quantity, price and etc. of a product which is of interest, in given quotation.

When creating a Quote there are few required fields such as Name, Potential Customer, Price List and Currency. Since I am going to explain the pricing of Quoting, I would urge the importance of assigning the Price List for a Quoting while all other fields are quite self-explainable.

Quote Product Units

Now we will pay attention to Quote Product and see how it works together with other components we learned in first Part of this article.

When creating Quote Products, it is required to populate Product, Unit and Quantity.

Now I am adding the Product Called “My Product 001” and Unit lookup pop-up shows all the Units under Unit Group of Primary Unit (Each). This is because, when we create this product in product entity we have specified that Unit Group. If we use a product which got Weight Unit Group, we might see all the Units associated to Weight such as 5kg Pack, 3Kg Pack and so on.

Quote Product Price Calculation

Now I save the Quote product with my values. Quantity is 7 and Unit is Each. Now we get auto calculated total for the Quote Product as below.

Price per Unit is the amount we mentioned in the Price List for “My Product 001” for “Each” unit. below is the calculation for Amount.

Amount = (Price per Unit – Volume Discount) x Quantity

In this case, Amount is also equal to Extended Amount too.

Now what is Volume Discount? If you read the first part of this article, it was explained about a lookup to set Discount List when creating Price List items. In this case, I have assigned a Discount List for the Pricelist Item of this product for Each Unit. Particular Discount List contains a Discount as below;

This simply tells to give $ 3 discount if quantity >= 6 and quantity <= 10.

Note: Since Discount List has to be assigned to Pricelist Items, it has to be assigned to all the Unit records for same product. In other terms, this same discount will not be applicable for the same product comes as Dozen or Cartoon unless it’s assigned for relevant PriceList Item records.

Apart from them, there are two more editable fields which I filling now. I put Manual Discount 50 and Tax 100 then save the record again. Below is the result.

In fact below is the equation of Extended Amount.

Extended Amount = Amount – Manual Discount + Tax

Dependencies you may note in Quote products

1) There are more products in the product entity, but I see fewer products in product lookup from the Quote Product form.

Explanation: You see only the products associated with the relevant Price List. In other terms, there should be at least one PriceList Item with the product to be seen here.

2) After populating a product to Quote Product, when try to set the Unit, I don’t see all the Units come under relevant Unit Group.

Explanation: Though this product is associated with relevant PriceList, it hasn’t got PriceList Item for all three Units, but only for the shown Units. In this example, PriceList got only one PriceList Item for this product and it is for Dozen Unit. (Need records for Each and Cartoon)

Quote Price Calculation

Once you complete play around with Quote Product, you are required to click the Recalculate button to get correct Quote totals. I got below sample totals for a Quote with a couple of Quote Products.

In fact, below are a couple of important formulas;

Detail Amount = Sum of Quote Products (Extended Amount – Tax)

Total Tax = Sum of Quote Products (Tax)

Quote total pane also got a couple of editable fields. I put my own values and recalculated to get new totals.

I have below formulas now;

Pre-Freight Amount = ( Detail Amount  x (100 - Quote Discount % ) / 100 ) – Quote Discount $

Total Amount = Pre-Freight Amount + Freight Amount + Total Tax

You will notice there are two kinds of Discount fields in the pane. One is percentage and other one is dollar amount. I have filled both fields to present a universal formula, but in practical world it’s advised to use one of those to keep it simple. These values are one time discounts that applied to the Quote total.

1st part of this article: Sales process – Part 1 – Product Catalog
3rd part of this article: Sales process – Part 3 – Modifying calculation of quote product
4th part of this article: Sales process – Part 4 – Modifying calculation of quote

Sales process – Part 1 – Product Catalog

Microsoft Dynamics CRM got flexible features to cater most of the pricing needs for products and services. Here I am explaining how they will fit in to your scenario. Here my starting point is Product Catalogue. Product Catalog is nothing more than few purposely designed entities. If you click settings > Product Catalog, you will see below screen with the entry points to four sections.

 



Unit groups and Units

First thing first! It is important to understand the relationship of Unit Groups and Units within the context of usability. This is fundamental physics! Any product should have a method of measuring.

Primarily most of the products can be count as integers (i.e. each). For example we can count Cars, Generators, computers, tables or etc. In day to day life, we have defined different packages of items for ease of usage such as cartoons, dozens and etc. Best example comes to my mind is beer. When we got o bar we can ask for one or two... but when we order them for a party we might order beer packs of 24 or 26 or etc. In CRM, these countable items can be defined as one Unit Group while, as same as the example mentioned, other “item packs” can be different Units under same Unit Group.

Now I am considering this Unit group as my Primary Unit group. CRM allows me to define many Units under this. Once you created one Unit Group, you can click the Unit link shown as an associate view, where you can add you’re Units. Suppose I define a dozen. Below is the simple form I need to fill. This explains dozen is created by multiplying Each by 12.



Also I can define a Cartoon which is 5 dozens.  This is the view I see all the relationships of Units under my Unit Group called “Default Unit (Each)”

Now I realize there can be different other products which can’t be measured with my primary unit group. Ex: Metal, Wheat, Cement and etc. Now I know they are measured by weight not the number of items. So I need another Unit Group for weight. Obviously, I can again define my Units under this Unit Group. Here I have added my second Unit Group;

 

Within Weight, I have defined different weights as Units. From this illustration you should realise that my primary unit for Weight Unit Group is 1kg and I have defined different packs of different weights based of 1kg.

Hope this explains that you can define whatever the measurement and units goes with your product or service. It can be length or time or etc.

Product and pricelist

Now only we can add records to products and pricelist.

When creating a new product you are required to populate both Unit Group and Default Unit. Always Default Unit look up shows you the values according to the Unit Group you selected.

Pricelist is the next important entity that keeps prices of products for their different units. Pricelist keeps all those information as PriceList Items. Please check a sample pricelist item as bellows;

This pricelist item says the price of the product for a Dozen. This implies, typically we need two more records for the same product for each and Cartoon.

Now we will consider this case. When I open my second product I see below error message in the beginning of the form. It says I haven’t set the default price list for the product.

In fact, now I am trying to open the lookup and set it, but I can’t see any pricelist in the pop-up lookup window!  This is because; price list doesn’t contain a pricelist item for this given product.
Now you are required to add a pricelist litem for this product before making any use of this product.

Discount Lists

In price list item, there is another special lookup called Discount List which obviously is to select a relevant Discount list for the record.

Discount List contains different Discounts under it. Discounts are simply discount amount /Percentage you get for buy different numbers. For example this Discount says that buyer gets $3 of discount if buy 4-10 of this. So user is free to define many Discounts under Discount List. Obviously user can have many Discount Lists to be attached to different pricelists.

When quoting, these discounts are being applied automatically.

2nd part of this article: Sales process – Part 2 – Quoting
3rd part of this article: Sales process – Part 3 – Modifying calculation of quote product
4th part of this article: Sales process – Part 4 – Modifying calculation of quote