Order returns and refunds

Change an order-return status

Select a supported state. The guide then takes you through the correct route, the checks to complete before making changes, the workflow in order, and the evidence to review afterwards.

Audience: Purchasing staffPermission: purchase_order_return capabilityModule v1.7.9
Jump to steps
Where to goAdmin Area → Purchase → Order Returns → open return → Status
Before you start
  • Use an account with purchase_order_return capability and confirm the intended record or setting before making a change.
  • Follow the exact route above. If the screen or action is absent, check module activation, ownership and permissions rather than using another person’s account.
  • Use controlled test data for configuration, integration, email, AI, payment, portal or automation changes before production-wide use.

What you’ll accomplish

Select a supported state. The instructions reflect the supplied module’s registered menus, controller actions, views, settings and code-backed validation flow.

Follow these steps

  1. Go to Admin Area → Purchase → Order Returns → open return → Status.
  2. Go to the exact setting, option or record named in this guide.
  3. Enter or select the required value; leave unrelated options unchanged.
  4. Save the form and wait for the success response.
  5. Reload the page or open a controlled record to confirm the stored value is being used.

Fields and options to review

Return sourceReturn type, related purchase order/invoice or other source, vendor and selected items.
Return detailQuantity, warehouse where available, reason, amount, status, attachments and refund records.

Rules the system enforces

  • Order-return states exposed by the register include Draft, Processing, Confirm, Shipping, Finish, Failed, Cancelled and On hold.
  • Approval and refund actions are separately validated from basic record editing.

How to confirm it worked

  • The supported change an order-return status flow completes without bypassing permission or validation checks.
  • The resulting record, setting, status, file, delivery event or external response is visible from the relevant workspace.
  • Unexpected validation, provider or linked-record errors are investigated before retrying.

Security, privacy and operational checks

  • Apply least privilege to purchasing, vendor, invoice, payment, return, contract and report permissions.
  • Verify vendor identity, bank/payment details, tax, currency, totals and approvals before creating financial commitments.
  • Treat public links, signatures, portal files, attachments and exported reports as controlled business records.
  • Test settings and automated jobs with controlled records before production-wide use.