- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on ‎03-09-2021 05:58 PM
While we're still currently on Orlando, I think this would apply to almost any supported version. Note that this simple solution would apply in environments following a similar Catalog Item pricing framework.
Not all Catalog Items have standard pricing models associated with them. For instance, we provide a workflow driven procurement request we call "PurchaseNow", where the Requester provides a total cost for items being requested in a string variable. However, the RITM's Price field and the Variable Formatter available in the Approver form have no default or OOB method to write that cost string into the Price field. To solve that problem, the best method turned out to be a fairly simple Business Rule on the Requested Item table (sc_req_item).
Note that the code below handles integers and decimals okay but does not address the issue of other non-number characters in the variable's string field. That would need to be handled with some more code depending on your environment.
Create the Business Rule with these attributes:
Table: sc_req_item
Run at: Server
Advanced: checked
When to run:
When: Before
Insert: checked
Update: checked
Filter Conditions: [Your Request Item] or other conditions befitting your environment
Actions:
We leave this blank, although you may find you need to configure something in this section
Advanced:
Conditions:
None
Script:
(function executeRule(current, previous /*null when async*/ ) {
// Copy string value from variable to RITM Price field
current.price = current.variables.purchase_total_cost;
})(current, previous);
The other side benefit to this is that if the variable's string value changes in the active RITM or associated Workflow Tasks, the price field also updates in real time.
Please mark as Helpful if applicable. Thanks!
- 2,267 Views


- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi,
I'm unsure if this is necessarily a good idea to continue to have this updated. It may have worked in your scenario, but having this as a business rule after it may have processed through approvals (if applicable) could bypass certain policies and other standard procedures (especially because the Request level price will adjust with the new RITM price -- so now you have multiple levels involved beyond just the RITM).
I think the post is more suited to just say hey...if you need to use an alternate price, you could do so through a variable value and set the record price with that.
Just throwing that out there in case others who don't actually catch all the other processes involved here.
Please mark reply as Helpful, if applicable. Thanks!
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Allen, thanks for the comment. It doesn't bypass approvals. In fact it provides more information to our approvers at first glance if all they're interested in is the total cost. As for the other cautions, you point out, eg "especially because the Request level price will adjust with the new RITM price", I agree. It's not an issue in our environment, but I suppose it could be other's.


- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi,
It does bypass approvals if there is a set approval amount that people have already approved and then later in the task steps...someone orders something else or pushes up the price...since you mapped it to a variable that can change (with your business rule).
So yeah, it can "bypass approvals" in the context that those approvals already happened and then the price gets adjusted later.
Make sense?
But either way, glad it works for you. My point is, there's a statement to say where the price can be changed and used with a variable...versus...saying where the price can be changed and used with a variable and then update that price all through the flow.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
I struggled with this requirement as well and came up with a convoluted solution which leverages the OOTB pricing functionality, but is very complicated. See below post:
How to create a catalog item with a user specified cost - IT Service Management - Question - Service...
After seeing this post, it made me think maybe I could have just gotten away with a simple business rule and just override the price after RITM creation.
Are RITMs not generally static after their creation?
From my understanding the cart item is effectively converted to an RITM after cart submission, and after that point there is no way to get that data back into the ESS cart widget etc such that an end user could reconfigure their request and update the price. Is that not the case? What would cause an RITM price to change after submission?
Not arguing, just genuinely curious. Thanks!
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
@Allen Andreas, not sure why you continued to push back when I told you it didn't matter for the way we do approvals in our environment. I understand your environment may be different. However, given that I offered a possible solution for those in a similar environment to ours, each administrator needs to weigh what works for them and their environment. One thing I didn't clarify is the the requester cannot adjust the price after the RITM is submitted, as the variable and RITM's price field are set to read-only. The fulfiller is the only one that can update the price/cost and they would have to check with the approver if it significantly impacts budget plan lines. However, when the scenario comes up, it's typically about small changes to the amount, which can be made only by the fulfillers.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
@jamesmcwhinney , apologies for my late response. Once the requester submits the item and the RITM is created, the requester cannot adjust the amount in the cost variable or the RITM. Only the fulfillers can adjust and they wouldn't adjust it there without talking to the approver if it impacted budget plan lines.