I was recently tasked to create an error message when a price quotation's total price is over 50,000 NIS and the quotation is not connected to an opportunity. This is more difficult than it sounds, as the price comes from the price quotation's lines. The standard scenario would be that a user opens the price quotation, adds lines then exits the price quotation, possibly changing the status of the quotation. If the status is changed, then a pre-update trigger would seem to be the place to put the check about the quotation's price. But if the status is not changed, no event occurs at the quotation level and so no code will be triggered. After all, the post-form trigger performs operations when a form is exited, provided there were insertions, updates or deletes in the form [emphasis mine].
One event that is guaranteed to occur is the item form's post-form trigger (this saves having to write both post-insert and post-update triggers) that will be triggered when the amount in the line changes. Here one would have to write code that sums the prices in the lines connected to the price quotation and then checks whether this total is greater than the designated price. I don't like this too much as the same check will be executed several times (once for each line) and also variables that belong to the price quotation form have to be named with a double dollar sign (because they're in the parent form), like :$$.BRANCHNAME. Whilst this isn't a problem, it's one more thing that has to be remembered.
Whilst idly looking through the SDK for the description of the post-form trigger, the search found a system variable whose acquaintance I had yet to meet: ACTIVATE_POST_FORM. Its description is assign it [the variable] a value of Y in a PRE-FORM trigger to activate the form's POST-FORM trigger upon exiting the form, even if no changes have been made [emphasis again mine]. This is exactly what I need! In the private post-form trigger I included the private pre-update trigger, so one way or another, the error message will be activated as requested.
This technique makes certain checks in forms much easier.
By the way, I couldn't use a business rule as I had to check more than three conditions.
From experience I'd warn you to check what happens in the child forms of that item form. I think you'll find that setting that variable causes all the children's POST-FORMs to always run, too, and it's not practical (or possible?) to unset the variable for them. When I encountered this I solved the problem by adding a condition to my post-forms which is based on a variable I set in a POST-INS-UPD-DEL trigger. But that was a custom form and if those child forms are standard you might not want to change those triggers.
ReplyDeleteIn general I'm not clear why you need the POST-FORM to run if the user didn't actually make changes. You run the risk of trapping a user in the form when he/she wasn't responsible for the excess price and is unable to change it.
Here's the scenario: user opens price quotation (CPROF). User enters items (CPROFITEMS) into the price quotation such that the price of the quotation is greater than 50,000 NIS. User exits price quotation. As no change has been made in CPROF, the (private) PRE-UPDATE trigger won't fire, neither would the (private) POST-FORM trigger. BUT due to the special variable being set, the POST-FORM trigger will execute and will check the value of the quotation.
ReplyDeleteI ran the form with this scenario: it works. We don't want the user to leave the form without connecting an opportunity.