Automatically Consuming a Consumable?

[CJB]

Hi, I'm trying to figure out a way to add a RunScript to a workflow (or another option) that allows for consumables to automatically be consumed.

We use a form that goes through a workflow.

I'm using this code that someone was very nice to upload on here, but I'm having trouble getting it to work properly:

var this_consumable = current.variables.alm_consumable;

//The this_consumable variable is a Reference variable used to select the consumable from the available stockrooms.

var this_qty = current.quantity;

var this_user = current.request.requested_for;

current.variables.alm_consumable_pull_from_stock = (" Qty "+ this_qty + "|" + this_consumable.getDisplayValue() );

//this line prints the value to a single line text variable on the Task form.

var new_sys_id = new Consumables().splitForeground(this_consumable, this_qty, '10', '', '', '', '', this_user);

//this is the script include that actually consumes and assigns to the user

Under consumables, the consumption is there, but it ends up looking like this. I need it to at least have the Display Name, if anything.

Thanks.

[Mark Stanger · Accepted solution]

Consuming a consumable should just decrement from the quantity of an existing consumable, not create a new record.  Are you saying that it's creating a new record in your consumables table?  If your script isn't working, it's probably because of one of four things (some of which are probably obvious to you but I'll include them anyway)...

1)  The variable 'alm_consumable' isn't really referencing the 'alm_consumable' table

2)  The variable 'alm_consumable' isn't really a reference variable

3)  The variable 'alm_consumable' isn't really named 'alm_consumable'

If you take a screenshot of the back-end view of the 'alm_consumable' variable I can help you validate these.

4)  Your run script in your workflow is right at the very beginning of your workflow.  Sometimes the timing of the creation of the 'sc_req_item' record is such that the 'sc_request' record doesn't actually exist right at the exact second that the workflow kicks off.  This would cause your 'this_user' variable to pick up an incorrect value because the request (and, in turn, the requested for) wouldn't be available yet.

I just tested the following script from the 'Scripts - Background' module in my own system and it ran successfully.  You can use it to do a quick test independent of everything in your workflow script just to make sure the actual consumption is working like it should.  Then you should be able to isolate to one of the 2 factors above (consumable ID or user ID) for sure.  Just replace the sys_id in the first line with the sys_id of your consumable to test.

var this_consumable = '2357460637732000158bbfc8bcbe5d0e';
var this_qty = '3';
var this_user = gs.getUserID();
var new_sys_id = new Consumables().splitForeground(this_consumable, this_qty, '10', '', '', '', '', this_user);

[Mark Stanger]

Let me know what you find here.  I'm curious to hear what the problem is in your system.

[CJB]

Hey Mark, 

Pardon my ignorance, I'm still a ServiceNow newbie, but how would I access the back-end of the variable? I've gone through the asset management workbook and my coworker wanted me to try completing a legitimate task now.

I think I can rule the 4th option out. I made sure to add the RunScript after the workflow confirmed that there is inventory (this is still manually set where someone goes in and selects whether there is stock or not). 

Thanks.

[Mark Stanger]

No problem.  I'd agree on #4 as well.  It's literally a fraction of a second so unless it's the very first thing it isn't the issue.

As for the variable, from the catalog ordering screen you can right-click the variable label and select 'Configure Variable' to get to the variable definition.  You can also get there through the item definition.