Newbie question about what determines an asset shows in Sourcing tasks

[clktester]

I'm new to this so please humor me. We've loaded models, then assets into the system. We're using Tokyo / HAM Pro. 

One model was published to the product catalog. The rest of the models don't appear to be. (probably have hundreds of models). 

Once requested, the task to source that model shows local, transfer or purchase. All seems to work fine.  

Question 1: From my understanding in order for local to show in stock, the location of the requested for must match the location of the stockroom. Is that right? 

Question 2: In order for other sourcing tasks to work, the model has to have vendor checkbox checked. Is that right? 

For some reason, it appears that some assets show as 'sourceable' assets through the various sourcing workflows and others to do not.

So a little confused on what makes a model and the corresponding assets tied to the sourcing tasks? If that makes any sense. I'm afraid we don't have things set properly on the models or assets and that down the road we won't be able to utilize the ootb workflows for sourcing. Right now we're doing a manual process with the PR when no items are in stock. Going forward it'd be nice to use the ootb PR workflow. Thanks for any info you might care to share. 

[Amit Gujarathi · Accepted solution]

HI @clktester ,
I trust you are doing great.

Here are the answers to your questions:

Question 1: To have the "local" option show as in stock, the location of the requester must match the location of the stockroom. This ensures that the requested model is available in the same location as the requester.

Question 2: In order for other sourcing tasks to work, the model must have the vendor checkbox checked. This indicates that the model is associated with a specific vendor and can be sourced through various workflows.

Regarding the confusion around which models and assets are tied to the sourcing tasks, let me explain. For a model to be tied to the sourcing tasks, it needs to be properly configured in the system. This includes checking the vendor checkbox and ensuring that the model is published to the product catalog. Only the model published to the product catalog will be available for sourcing tasks.

Similarly, for assets to be considered as "sourceable" assets in the various sourcing workflows, they need to be associated with a model that meets the aforementioned requirements. If an asset is not linked to a model or if the model is not configured correctly, the asset may not be available for sourcing tasks.

To utilize the out-of-the-box (OOTB) workflows for sourcing, it's essential to ensure that the models and assets are set up properly. By following the steps mentioned above, you can make sure that the models and corresponding assets are tied to the sourcing tasks, enabling you to utilize the OOTB purchase request (PR) workflow seamlessly. This will eliminate the need for a manual process when items are out of stock, improving efficiency in your IT asset management.

[WB]

Hello,
Firstly, your post has been very helpful and gave great insights on how the Sourcing Task works!  
Secondly, I still have a problem with getting the "Vendor Purchase" button to be functional, it's stuck as Read-Only.  I think it may be related to the Vendor Checkbox you mention in Question 2:  "In order for other sourcing tasks to work, the model must have the vendor checkbox checked." 

Unfortunately, the Vendor Checkbox field isn't showing in our Sub-prod instance on the Catalog Item or Hardware Model. 

Please advise where to look for Vendor Checkbox field or if it goes by a different name on the back end.  Thank you.

[Wally Horne1]

The Vendor checkbox is on the company record, which would be referenced by "manufacturer" in the hardware model record.

[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!!