CRM 2011 Opportunity Revenue field is read only
November 14, 2011 2 Comments
I’ve just had a slightly strange situation with some customisation for a CRM online project I am working on that I thought I would share in case anyone else has a similar experience with this particular scenario or other odd results of customisations which may have a related cause.
Customising the Opportunity form
I have been customising various entities and forms to build the system to suit the particular customer’s requirements. One of the things I was changing was the Opportunity form. I added some of the custom fields, moved some things around and tidied is up generally. Published and everything seemed fine.
Estimated Revenue always read only
Then I noticed that I could not put a value in the Estimated Revenue field. It was disabled, dimmed as unavailable, read-only, “move along, nothing to do here…”. Nothing I did would change this, Est. Revenue was always read only.
I had quite deliberately already changed the “IsRevenueSystemCalculated” field default to “User Provided”, and this is the value it correctly showed up on the form.
In general this organisation will be quoting their clients as part of longhand written proposals or formal RFPs for very flexible services work which does not lend itself well to using the Product Catalogue, although they may do that later for standard, fixed price, “commodity” services they offer. So their Opportunities will be used to manage the sales pipeline but not to figure out the values for them, and user provided figures are the most sensible way to handle this.
If I changed isrevenuesystemcalculated to “System Calculated” it correctly added in a value (£0.00 at the moment since I have added no line items) and it remained disabled, as it should. Change it back to “User Provided” and nothing happens, still read-only and unavailable. Currency was set, no Price List was added (and none needed as there would be no line items). All very strange.
What else could be causing this?
I had included Est. Revenue in the form header, and thought this might be causing the problem in some way because it would be a read-only field, but I removed it and it made no difference. I checked and rechecked that there were no scripts or anything else that could be affecting this behaviour. Nothing.
But one other thing that I had changed from the default OOBE is the way the field was displayed – rather than a pair of radio buttons I had chosen to save some space on the form by showing isrevenuesystemcalculated as a picklist since the user would only very rarely want to change this.
Switching back to radio buttons fixed the problem.
Why would this be buggy?
So it seems that the built-in functionality which is triggered by changing this field and updating the Est Revenue field accordingly is not particularly flexible. As far as my testing shows, it looks like it explicitly uses the status of the radio buttons as part of the DOM, rather than the underlying value of the bit field to figure out the state of the user selection in the isrevenuesystemcalculated field.
I would argue that this is a bug, since it should be possible to display this field in any way I choose. Albeit if I chose a single check box the label would need to be more explicit than simply “Revenue”, and this would not work as tidily in any case as selecting or clearing a checkbox does not trigger an “onChange” event until the focus changes (ie you click away from the field).
Have you had any similar experiences where the built-in functionality is very picky about how things are displayed, or where changing the default forms has affected things in strange ways? Please feel free to share via the comments.