Sourcing & Stockrooms

[clktester]

From what I read, it appears the user's location must match the stockroom location if you want the 'Consume' button to illuminate when using the Sourcing button from a Purchase Order. 
That's great, but not all users are at the warehouse. 

Since Location has hierarchies, how do you get a stockroom to use the parent location so you don't have to have all the users at the child location of the stockroom? Could you for example create a location called New York, then have the users' locations be Rochester, White Plains, etc. and when sourcing because the stockroom is in the State, the system recognizes the children and sees the children are under New York?

Also does Stockroom type has anything to do with how the sourcing / consume process work/behave?  

Thanks in advance. 

[Amarjeet Pal · Accepted solution]

Hello @clktester ,

This is a pre requisite to use the stock room . Orelse go to stockroom and make it available in bulk. You need to make sure all users have their location same as stockroom. If not then you need to source it or you have the transferable stocks option.

In terms of whether stockroom type affects how sourcing/consume process works or behaves, it depends on how the stockroom is configured in ServiceNow. The stockroom type field can be used to classify stockrooms based on their usage, such as whether they store consumables or assets. However, this field does not directly impact how sourcing and consume processes work in ServiceNow.

Hope this answer your questions. Just keep it simple.

Thanks,

Amarjeet Pal

[ThomasWright3]

Something to add here that I discovered by trawling through the ProcSourceRequestManager script include. If you include a location reference variable on the hardware catalog item with the name "location" it will override the requested_for.location on the sourcing task!

Check out the code in the ProcSourceRequestManager  _getRecordObject method and you'll see references to variables.location.

I've verified this does indeed override the Requested for's location on the Sourcing task within the HAM workspace running on a Xanadu environment. The local/transfer stockrooms change depending on what is local to the location variable rather than the requested_for.location.

Crazy this isn't documented anywhere!!

[DavidWallace1]

That's crazy! I can think of all kinds of ways to use that! 😁

[Thomas Wright]

Yeah indeed!

My current use case is desktop deployments to desk locations. I was thinking I would either have to butcher the sourcing engine or just not use it entirely (very sad face!).
This'll keep it all OOTB and allow people to see stock levels etc, lovely.

Combined with my previous butchery of the sourcing engine to allow model substitutes to be selected within the sourcing UI I don't have any use cases that can't be covered by the sourcing engine.. well except for some real nice-to haves such as being able to filter down the in stock assets by attributes on the asset/CI which would be really nice for server deployments where you need a server with 128GB ram vs 64GB with the same model.