Ramp Manage Procurement

Manage Procurement

Use this skill for purchase order lookup, unified procurement request lookup, status tracking after submission, pending procurement approvals, and safe request approval or rejection.

For a new or existing draft that the user wants to fill, review before submission, or submit, use ramp-submit-procurement-request. For an approval queue that spans requests, bills, reimbursements, or transactions, use ramp-approval-dashboard.

Do not use it for bill approval/payment, card transaction cleanup, reimbursements, vendor document upload, accounting recoding, or drafting contract edits.

Rules

• Use purchase_orders for PO lookup/detail. Use requests for unified request search, request detail, pending approval queue, approval, and rejection.
• Keep identifiers labeled. purchase_order_id, unified_request_id, and spend_request_id are distinct. Approval acts on the unified request UUID, not the PO UUID.
• Use --agent for responses you need to parse.
• Use --json for search filters. The CLI validates unknown JSON keys and enum values, so use --dry_run --json ... when checking payload shape.
• Use exact pagination cursors returned by the API. Do not trim or rewrite them.
• Procurement schemas do not return deep-link URLs. Present returned identifiers and statuses instead of inventing links.
• Do not approve or reject without first showing details and confirming the user's intent.
• When requests get returns a non-null original_request, treat the request as a change request; before approval, verify that original_request identifies the intended original approved request and review every entry in change_request_diff fields, including each old and new value. Stop if the source or diff is absent or unexpected.
• A LINE_ITEM diff includes only changed values. Overlay a present new_value on old_value: a null property means unchanged; the whole new_value is null when the line was removed. When a line item's UUID matches the original, its tracking categories, custom fields, withholding rates, and external IDs carried over unchanged; do not report them as changes.
• For rejection, include the user-supplied or user-accepted reason in --thoughts.
• PO amount fields are numeric currency units with a currency code. Display them directly; do not apply cents conversion.

Workflow

1. Search POs first when the user gives a PO number, vendor, or procurement record. filters.search matches PO numbers, request names, and owner names; it does not match vendor names. For a vendor search, resolve the vendor UUID first, then filter POs by payee_uuids:

   ramp vendors search --search_term "Figma" --limit 10 --rationale "Find the vendor UUID for the purchase order search" --agent
   ramp purchase_orders search --json '{"rationale":"Searching purchase orders for the resolved vendor","filters":{"payee_uuids":["{vendor_uuid}"]},"limit":10}' --agent
   

   For a PO number, request name, or owner name, use filters.search directly:

   ramp purchase_orders search --json '{"rationale":"Searching purchase orders by PO number","filters":{"search":"PO-1234"},"limit":10}' --agent
   

   If a known PO number is not returned, the spend request may still be pending and the PO may not be issued yet. Search unified requests scoped to purchase orders:

   ramp requests search --json '{"rationale":"Searching purchase order requests before PO issuance","filters":{"search":"PO-1234","unified_spend_request_types":["PURCHASE_ORDER"]},"limit":10}' --agent
   

   Unified request search and pending rows include unified_request_id and may include purchase_order_number, but they do not include purchase_order_id. To move from a unified request row to PO detail, first call requests get with unified_request_id and use purchase_order_id from that detail response if it is present.

2. Get detail before summarizing or taking action:

   ramp purchase_orders get {purchase_order_id} --rationale "Reviewing purchase order details" --agent
   ramp requests get {unified_request_id} --rationale "Reviewing request before action" --agent
   

   The unified request identifier is named unified_request_id in request search, pending, detail, approve, and reject responses. Do not call purchase_orders get directly from a request search or pending row; list rows do not expose purchase_order_id.

3. Review pending approvals through the request queue:

   ramp requests pending --rationale "Reviewing pending procurement approvals" --thoughts "Reviewing pending procurement requests" --page_size 50 --request_types PURCHASE_ORDER --agent
   

   Paginate with the returned cursor:

   ramp requests pending --rationale "Continuing pending procurement approval review" --thoughts "Reviewing pending procurement requests" --page_size 50 --request_types PURCHASE_ORDER --start "{next_page_cursor}" --agent
   

4. Before approval or rejection, check the current approval step:

   ramp requests get {unified_request_id} --rationale "Pre-approval workflow check" --agent
   

   If approval_workflow.needs_user_action is not true, do not call requests approve; hand off with the identifiers and the current approval step from approval_workflow.steps.

   If original_request is non-null, also show its original spend request UUID, unified request UUID, and PO number, followed by the complete change_request_diff fields and old/new values. Confirm that the source is the original approved request the user intended to amend and that the diff contains only the expected changes. Do not infer a change request from names or amounts when original_request is null.

5. Act only after the user confirms the exact unified_request_id:

   ramp requests approve {unified_request_id} --action APPROVE --rationale "Approving confirmed purchase order request" --thoughts "Approved after confirming PO details with the user" --agent
   ramp requests approve {unified_request_id} --action REJECT --rationale "Rejecting confirmed purchase order request" --thoughts "Rejected: {confirmed_reason}" --agent
   

Output

For search results, keep rows compact and use fields from the command response:

PO number | vendor | amount | currency | PO status | id

For detail summaries, include available status and relationship fields:

PO number:
Vendor:
Amount:
PO status:
Request status:
Change-request source:
Change-request diff:
Promise date:
Linked bills:
Linked transactions:
Linked item receipts:
Unified request ID:

Before approval, state that approval acts on the unified request UUID, not the PO ID. For change requests, include the original approved request identifiers and old/new diff in the confirmation prompt. After action, surface returned unified_request_id, action, success, and message.

Handoff

Hand off instead of guessing when the CLI cannot complete the workflow, the current user is not the active approver, the user asks for unsupported edits, or the task belongs to bills, reimbursements, transactions, vendor documents, or contracts.

Include the identifiers and statuses you have:

PO number:
Purchase order ID:
Unified request ID:
Spend request ID:
Request status:
Current approval step: