>

Recommended Process for Rental Equipment Purchase Orders

Comments

14 comments

Date Votes
  • Himanshu

    Hi Phil,As per my current understanding - definitely not claiming full expertise, tagging few experts Pieter Du Plooy Chanh Huynh 

    Rental Tracking

    • If you’re receipting inventory without a PO, you can flag the item as a rental and set start/end dates. This is pretty straightforward and helps you see at a glance which items are rentals versus permanent additions.
       

    • For items with a PO, the rental flag isn’t always visible or captured in the same way. I was unable to fully confirm this.

    Reporting & Views

    • The “Inventory Transaction Items” screen will benefit here. You can filter for rental items (if flagged) and their dates, then save/export the view for regular review. This is how I’ve seen teams keep tabs on what’s still out and what needs to come back.
       

    Reminders & Returns

    • Reminders are mostly manual - I'm thinking activities or checklists against the supplier account. There’s no built-in automation (yet) for rental returns, so it’s on the end user to set up a process. Some teams use recurring tasks or calendar reminders to prompt returns.
    • To actually return the item, you create a Return transaction in the system. This decreases the item’s stock and keeps your inventory accurate.

    Workflow & Automation

    • It will be interesting to hear about how Workflow Builder may support scenarios like this.
    • Regular audits and dashboard reviews are best practice i believe to keep a track of receipt and returned.

    Invoicing & Payments

    • I am not sure if i understand your question about invoice approval and payment reminders (i believe you are referring to Dunning statements) which may need to separate it out to understand what's the ask here.
  • Philip Bathfield

    Thanks Himanshu

  • Philip Bathfield

    Pieter Du Plooy Chanh Huynh it would be great to get your view on the best practices and how are other customers are managing this process in practice?

  • Pieter Du Plooy

    We probably don't have many customers that uses Enterprise fully. 

    But to add, in the resource requirements window, you can right click one or many items that will be short and create a purchase or requisition order/s. The system will use the preferred supplier linked to the inventory item/s and create the purchase order/s. It will use lead times, min, max and re-order levels of the items to reasonably accurate create the purchase order. It's still someone's job to review before its approved and sent to the supplier.

    As for accuracy, the accuracy of any system depends entirely on the quality of the information provided to it. That is why some larger customers have dedicated warehouse staff and or buyers. It's their job to make sure the system balances.

  • Philip Bathfield

    Thanks Pieter Du Plooy 

  • Seth Halvaksz

    CC Ryan Ungerboeck 

  • Victor Nogales Junior

    Hi all,

    I analysed the possibility of using the Workflow Builder for this use case and it seems some aspects can be automated. However, I need your help to confirm I’ve understood the use case correctly and it functions as intended.

    Thanks,
    Victor.

    WORKFLOW BUILDER ASSESSMENT

    SUMMARY

    Please note this is a high-level assessment based on available API documentation and webhook specifications. A precise implementation answer would require a detailed technical analysis and hands-on validation in your specific environment.

    The end-to-end rental process, deficiency identified in Resource Requirements, requisition or PO created, item received, item returned, is only partially automatable today. The front half (requisition/PO creation and receipt) is well supported by the API and has webhook triggers. The back half is where the risk sits: there's no dedicated "is this a rental" flag on the inventory item catalog itself, and nothing pushes a notification when a rental comes due or when a return is posted. The good news is that the Inventory Transaction record does carry native rental fields (a rental flag, start/end dates, and a link back to the originating PO), and the API supports creating and posting that return transaction directly. So the pieces needed to build a monitoring or enforcement layer exist, they just aren't wired together automatically by Enterprise itself.

    TECHNICAL ANALYSIS

    Deficiency to Requisition/PO: generating a requisition or PO from Resource Requirements is a native Enterprise UI action (right-click short items, system uses preferred supplier, lead time, and reorder levels). The Requisitions API (GetRequisitionList, GetRequisition) is read-only, no POST/PUT, so this step can be read from but not triggered externally. PurchaseOrders/PurchaseOrderItems support full POST/PUT if a PO needs to be created or edited outside the native flow.

    Rental flag: there is no rental indicator on the master InventoryItems record, only generic Class/ProductGroup classification fields. Rental data instead lives on two places: PurchaseOrderItems carries DateIn, DateOut, and InOut, and the InventoryTransactions record carries its own RentalFlag (Y/N), StartDate, EndDate, and RentalIndefinite, plus PONumber/POLineNumber linking back to the PO and Status (A=Active, C=Closed) showing whether the obligation is still open.

    Posting the return: POST /InventoryTransactions exists specifically to create and post transactions, and TransactionType includes RET (Return) alongside Receipt, Adjustment, Issue, Count, and Transfer types. This means a return can, in principle, be created and posted through the API rather than only through the native UI.

    Webhooks: PurchaseOrderUpdated, PurchaseOrderItemUpdated, POApprovalUpdated, RequisitionUpdated, RequisitionItemUpdated, RequisitionApprovalUpdated, and ResourceUpdated are all available, good entry points for the front half of the process. There is no webhook for Inventory Transactions, Inventory Items, or Inventory Balances, so nothing fires when a rental transaction is created, closed, or overdue. Any monitoring has to be poll-based against GET /InventoryTransactions.

    Workflow Builder opportunity: trigger on PurchaseOrderItemUpdated when a rental PO item is received, then run a scheduled check against GET /InventoryTransactions filtering for RentalFlag=Y, Status=A, and EndDate at or past due. Where a return hasn't been posted, Workflow Builder can notify the buyer or warehouse contact, or, with careful validation, call POST /InventoryTransactions with TransactionType=RET to post the return itself, closing the loop that currently depends on someone remembering to do it manually.

  • Philip Bathfield

    A follow up question raised by VCET: “the key component  is the ability to identify rental items on PO's. The process (Resources Requirements > Create PO > PO Receipt = Increase Balance) works for CONSUMABLES, however we are using RTIC for EQUIPMENT, therefore the PO's are created when we need to cross hire AV equipment due to deficiencies and the inventory balance is only temporarily increased”

     

  • Philip Bathfield

    Pieter Du Plooy Victor Nogales Junior Ryan Ungerboeck A follow up question raised by VCET: “the key component  is the ability to identify rental items on PO's. The process (Resources Requirements > Create PO > PO Receipt = Increase Balance) works for CONSUMABLES, however we are using RTIC for EQUIPMENT, therefore the PO's are created when we need to cross hire AV equipment due to deficiencies and the inventory balance is only temporarily increased”

  • Victor Nogales Junior

    Hi Philip Bathfield , see my two cents below but I would like Pieter Du Plooy  and Ryan Ungerboeck to review if I'm misunderstanding or missing anything, as the below is based on documentation only.

    Please note this is a high-level assessment based on available API documentation and webhook specifications. A precise implementation answer would require a detailed technical analysis and hands-on validation in your specific environment.

    That's an important distinction, and it changes the identification step. I checked the master InventoryItems record more closely: it does carry a native Class field (IN100_RES_CLASS) with explicit values 2 = Equipment and 3 = Consumables. So the system can tell an AV/equipment item apart from a consumable at the catalog level, that part is structured, not freeform.

    What it doesn't tell you is whether a given PO for an equipment item is a permanent purchase or a cross-hire. That intent sits one level down, on the PO item / inventory transaction itself: PurchaseOrderItems.InOut (column PO101_INOUT_USED), DateIn, DateOut, and, once received, InventoryTransactions.RentalFlag/StartDate/EndDate. Unlike the Class field, these don't have documented value meanings in the model metadata, so I can't confirm from the source alone which exact value of InOut denotes "temporary cross-hire" versus a straight receipt, that would need to be checked against a real PO for a cross-hired item in your environment.

    So the identification logic for Workflow Builder becomes two-tier: filter to Item.Class = 2 (Equipment) first, since that's what separates AV kit from consumables, then within that set, isolate the ones flagged as temporary (InOut/DateOut populated, or RentalFlag = Y once posted) as the cross-hires that must come back out, as distinct from equipment bought outright to keep.

  • Pieter Du Plooy

    Hi Victor, 

    Sounds workable. 

    I spoke with Ryan probably about a year ago, about the ability to also have clear OPEX and CAPEX differentiation on PO's. The idea is, other than having it being flagged separate, it will allow different users with different approval levels to only approve what they can approve. Maybe a flag like this could also include a rental option? This rental selection could then mark the in out dates as active or not.

  • Philip Bathfield

    Thanks, Pieter Du Plooy Victor Nogales Junior can I use this to respond to the customer?

  • Philip Bathfield

    Pieter Du Plooy Victor Nogales Junior Ryan Ungerboeck please advise on a response I could use to get back to the customer with. Thanks

  • Pieter Du Plooy

    Based on what was shared above, it seems it might be possible via technical services and with the use of Workflow Builder. Also as per Victor, “A precise implementation answer would require a detailed technical analysis and hands-on validation in the client's specific environment.”

Please sign in to leave a comment.