HAM Procurement: Adding Existing Assets to Purchase Orders

[HMcNulty]

Hello experts!

My team and I are currently doing some research on the feasibility of adding existing assets to a purchase order as part of the assets received. We are working on an integration with a vendor that handles some of our asset inventory, and basically when a stock order is made for computers from that vendor, the assets will be created in our hardware table when we receive an API payload with new asset information from their Salesforce instance. The problem is, the OOB PO process is setup so that the asset tags and serial numbers are manually created in the hardware table by a user via the receiving process. Even when I have tried to manually add assets to the PO via scripting, its as if the PO doesn't even detect those assets have been added, and will still require me to receive as many assets as the order was for. Alternatively, a way to automate the manual UI for the receive step would work as well, but this seems less likely.

Has anyone had a requirement like this before, and what was your approach to solving it? We are trying to avoid any heavy customization to the OOB code if possible.

[Spencer Morris · Accepted solution]

Hi, you actually might not need to customize the PO process at all for this

OOB already handles assets that exist before you receive. They just need to be On order and linked to the PO line. When you hit Receive, the asset tag popup shows those assets and says they’re already created, so you just select them. Click Done and it trues up the received qty, then Submit updates the remaining qty and they flip to In stock.

So my guess on why your scripted ones weren’t getting picked up is the state. If they weren’t On order, receiving won’t see them. The fix should just be in your API code that creates the assets from the Salesforce payload. Make sure it sets:

• asset.purchase_line = the sys_id of the PO line (proc_po_item) record
• asset.install_status = 2 (the value for On order)
• serial / asset tag / model from the payload (if you only get serials you can type the tag in the receive popup)

If you want to see what OOB expects first, there’s a related link on the PO line, “Create hardware assets prior to delivery,” that creates On order assets the same way. Compare one of those to what your API creates.

Few things to watch:

• don’t let it create more assets than the ordered qty
• coalesce on serial so a resent payload doesn’t dupe stuff
• receive is still a manual click, but honestly that’s kind of nice since someone actually confirms the stuff showed up. Full auto receive is where it gets custom, because then you’re writing scripts to replicate everything the system does when someone clicks that button, handling any data a person would normally fill in by hand, and building exception handling plus a process for someone to actually work those exceptions