Monday, January 28, 2013 7:20 PM
I wrote a plug-in that fires on Order create to generate a unique order number (auto-numbering system). The order number is based on the "type of the order" (custom field), and the order numbers are sequential. The orders created in CRM will then be integrated with our ERP, which is why we are trying to use our own order numbers and not the CRM generated order number. The order number gets used as the name of the order, as well as the "ordernumber" and of course the "dynamics_integrationkey" since we integrate with GP. There are a number of solutions available in Codeplex for something like this, so didn't think this was going to be a big issue.
However, we have a need to allow users to create orders from opportunities. What I found when doing this is that CRM is not firing the logic that lives on the Create message for the order. I've done a bit of digging and it seems that creating an order from an opportunity is actually firing the GenerateSalesOrderFromOpportunityRequest message, which clearly is not calling the create message on the order. Looking in the plug-in registration tool, it does not appear that I can register plug-in code against this message. It looks like we are going to run into this same thing when turning an quote into an order.
Has anyone else run into this issue? Do you have any suggested work arounds? I can think of one, but it doesn't seem very appealing:
Have the auto-number logic also run on the Update message if the order number does not match the scheme for that order type. This forces someone to save the order again to get the right numbering though, and when initially opening the order it would not look "correct".
Monday, January 28, 2013 9:49 PM
I have good news and bad news. The bad news is that you're right. The Create event on SalesOrderDetail never fires (for whatever reason). The good news is that the Update event always fires (at least once and possibly more times) automatically after a SalesOrderDetail record is created. You will not have to make anyone save the record again. I just went through this whole process and I can tell you there are a couple of things to note (more mostly aggravatingly bad news):
- It appears there is at least one update associated with each create. This 'initialization' update appears to contain very few useful non-null fields (I did see there was a UnitPrice but not much else). Pre and Post images do not help flesh out this picture.
- There is then a second associated update. This has the relevant field information that was on the originally created SalesOrderDetail. It appears this is for the purpose of 'recalculating' the amounts from your pricing model.
- If your SalesOrderDetail Amount is $0 the second 'recalc' update does not occur :(
- On subsequent 'recalc' updates the UnitPrice becomes null making it effectively useless as a method of determining which update is running at any given time.
- Marked As Answer by juliahirscher Tuesday, January 29, 2013 1:59 PM
Tuesday, January 29, 2013 2:00 PMUgh, not what I was hoping to hear but I guess I'm not terribly surprised. Why this does not fire the logic that lives on the Create message is beyond me. Thanks for all of your insight - glad to know I'm not the only one who came up against this.