Question for reporting on consumable and asset allocations

Sean Addington
Tera Expert

Hello all,

I was wondering if anyone here would have some guidance on an issue I'm trying to sort out, and might be somewhat confused. For my organization, we're working on a project to manage our inventory tracking within our current ITSM suite. However, one of our requirements is to track what items are allocated/assigned to an employee, both for assets and consumables from a reporting standpoint based on PO and invoice information. This is primarily so equipment costs can be noted for the proper business unit.

From initial research, I started reviewing the "alm_consumable" table, but that doesn't appear to work for us since I'm not seeing anything that would refer to a PO or invoice there, as well as the fact that the expense lines would potentially have a quantity that is greater than what was consumed by the employee. Also, I'm at somewhat of a loss when trying to also track assets when trying to find when they were assigned to an employee while also providing info for the PO/invoice as well.

In reading some previous posts, I'm wondering if this would be something better suited for a custom table, but I wanted to see if anyone in the community would have any thoughts/input/guidance on this? Maybe I'm missing something in my thought process, or overthinking this when there is a much more simple solution on this.

Any help would be greatly appreciated otherwise.

2 REPLIES 2

Sean Witt
Tera Guru

Hey...a few things to consider as a starting point based on your questions.

 

One thing to keep in mind with Out of Box ServiceNow forms is that you often have existing OOB fields available in the underlying table structure, which just aren't included/visible OOB on the default view of the form. But it is an easy configuration change to pull any additional fields onto the form that you need. For example, the Consumable form already has fields in the table for invoice_number and po_number. I'm guessing they aren't included on the form OOB because a lot of organizations don't use the same level of detail in tracking lower cost consumables, versus other more valuable assets.

 

But you could easily pull those base fields onto the form to be available for use. There are a bunch of ways to see what fields are available in an underlying table, but two of the easiest are probably:

  1. Navigate to any list view for the table and personalize the list to see the available columns.
  2. Or from the form view, select the Show XML option from the Additional Action Menu (top left corner of the form). You can do a find (ctrl key and f) in the XML to keyword search for your term, like invoice or po.

 

On the asset form, the OOB form layout has a date/time field for "Assigned" along with an "Assigned to" field. So you should be able to use those for reporting.

 

From the top of the form in the Additional Actions Menu, for audited tables you can select History > Calendar and get the running history of form field inserts and updates. So when as asset state changes, or is assigned to a different user, the old value and new value are visible here:

 

find_real_file.png

 

 

 

find_real_file.png

 

Hope that helps some...

Sean

 

   

Sean,

I do appreciate the comments, and it does help a bit. On the asset records, I can pull some of the PO info by referencing the purchase order line items (proc_po_item) table to get PO info for the hardware assets, however I'm running into a roadblock on the consumables, since those would be ordered on different PO's/vendors.

From what I can see, those fields are blank, so my guess is that the data isn't being written to those when the items are received. I guess this is where I was wondering if there's something I'm missing, as I can't seem to find any business rules that would dictate this behavior, so maybe I'm looking at having to add something for this? 

If we just had to report on the assets, this would be the perfect answer for us and I wouldn't have any other issues. The thorn for me is the consumables since we have to report on that as well. Again, thank you for the response. I'll dig around a little further in the meantime, but if you have any other thoughts, I'm more than open to hear further as well. 

Thanks again from Sean to another. 🙂