Why isn't the request line field updated on the asset form?

[Adrienne Kueber]

The request line field is not updated on the asset form for transfer and local orders, and is only updated for purchase orders. In the AssetAutomationAPI script include, I can see that this is intentional as the OOB script include has a comment saying they are not populated (screenshot attached). Is there a reason why and are there any ramifications to populating the request line for transfer/local orders to mimic purchase orders? 

[Oscar D · Accepted solution]

Hey Adrienne, 

We meet again. 😛

The Request Line represents the initial request that led to the creation of the asset and resulted to incurred expense line. That is why the request line is located under the financial tab as it represents the request the result to the purchase. Typically, assets are created during the Purchase Order (PO) process, specifically when utilizing the Procurement plugin. The Sourcing and Transfer orders are responsible for moving the asset around, so it wouldn't make sense to update the Request Line in those cases, as they didn't contribute to the asset's creation. 

It's important to understand that when you update the Request Line on an asset, it triggers a Business Rule (BR) that updates the configuration item on the Requested Item (RITM) associated with the asset. This update to the RITM's configuration item, in turn, triggers another update that modifies the configuration assigned to the request's "requested_for" field, including location. These changes are then synchronized back to the asset via the Asset-CI field sync.

I mention this because if you update the Request Line on the asset using a script, and the "Assigned To" field differs from the "requested_for" field on the original request, it could overwrite the assigned person or cause mismatches in unexpected ways between different fields. For example, if an asset is reserved for an individual and located in a stockroom, when you update the Request Line then the assigned to updated on CI which sync to asset, a business rule stops the update as its reserved, this sync backs to CI clearing assigned to, but the location is maintained from assigned to. Now you asset is located in a different location than the associated stockroom. Therefore, it's advisable to only update the Request Line on the asset if the request indeed resulted in the creation of the asset. Otherwise, consider using the Consume Asset Task or Transfer Order when scripting something unrelated to the asset's creation record.

In the scenario where you are integrating with vendor whom is managing your inventory and utilizing HAM pro the process would look something like this: 1) Stock Order is submitted in which you order a bulk amount of models which in-turn creates all the associated asset. The Request Line would be tied to the bulk request. 2) Vendor send asset to end user then you could utilize a transfer order or consume to track the deployment of device. Repeat step 2 every time the asset is deployed. 

I hope that help,

Oscar 

[Adrienne Kueber]

Hi Oscar,

Great to hear from you again!

Thank you for providing such a detailed explanation of how the Request Line interacts with assets and the potential challenges that can arise when updating it. It's clear that maintaining the integrity of the Request Line is crucial for accurate record-keeping and ensuring that assets are correctly associated with their respective requests.

Your insights on the integration process with vendors using HAM pro are particularly helpful. I get the importance of having a structured approach when dealing with bulk orders and asset deployments to avoid any discrepancies.

Your explanation clears up a lot of potential confusion, and once again, thanks for your wisdom 😄

Best regards,

Adrienne

[Alex Mikesell]

Hi Oscar, do you happen to know the name of the OOTB BR that provides this function you called out?

 This update to the RITM's configuration item, in turn, triggers another update that modifies the configuration assigned to the request's "requested_for" field, including location. These changes are then synchronized back to the asset via the Asset-CI field sync.

[Oscar D]

@Alex Mikesell - Find the two BRs below. 

• Update Request Item CI
  • Runs on alm_hardware table that will update CI on the sc_req_item with the asset.ci once Request Item is update on the alm_hardware record
• Assign from Stock
  • Runs on the sc_req_item when the configuration item updated from above transaction.