Returns
Returns
Purpose and when to use this record
Reverse eligible sale quantities and taxes, calculate fees, and track how much of the refund has been completed.
At a glance
-
Identify it by: Date Created, and Refund Status.
-
Check its business context: Sale, Customer, and Warehouse.
-
Why care: Customer, warehouse, quantities, prices, tax, payment, and fulfillment represent different parts of the transaction. Review each before treating the sale as complete.
-
Why care: Treat posted, processed, paid, reversed, and edit-locked states as controls—not ordinary descriptive fields. Confirm the source transaction before changing any state that the screen permits you to change.
Before you begin
You need the Brisk permission for the action you are taking on returns. If a Create, Edit, or Delete control is absent, do not work around it with another user’s account; ask an administrator to review your role.
Create a return
Create a return only after confirming that the source document or operational event has not already been entered.
-
Select the business context first: Sale, Customer, and Warehouse.
-
Enter the required identifying and operational values: Date Created, Balance To Refund, and Tax To Refund.
-
Review Refund Status, and Edit Locked deliberately; these choices control availability or workflow rather than merely describing the record.
-
Save the return, then confirm Date Created, and Refund Status on its detail page before continuing.
After saving: Confirm returned quantities, taxes, fees, tender, and Total Refunded before marking the refund complete.
Delete a return
Delete this return only when it was entered by mistake and no downstream history depends on it. Use a reversal, void, credit, counter-adjustment, or status correction for a real event that later changed.
Before confirming, check for related Inventory Records, Return Invoice Applications, Return Payments, Returned Items, and Transactions. Brisk may refuse deletion when another record depends on this one; resolve the duplicate or use the supported correction workflow instead of breaking the trail.
On the confirmation page, verify Date Created, and Refund Status. After confirmation, return to the Returns list and make sure only the intended return was removed.
Review return details
Use the detail page as the shared record of what this return currently means. Verify Date Created, Total To Refund, Refund Status, Total Refunded, and Edit Locked before relying on it for a decision.
Follow Sale, Customer, and Warehouse to determine whether the issue is on this return or on one of those linked records.
Next check: Confirm returned quantities, taxes, fees, tender, and Total Refunded before marking the refund complete.
Edit an existing return
Edit this return to correct or complete the same source document or operational event; use the supported reversal or follow-up workflow when the business event itself changed.
-
Open the detail page. Compare Sale, Customer, and Warehouse with the supporting document or approved request.
-
Recheck Customer, Date Created, Total To Refund, Refund Status, Total Refunded, and Edit Locked, plus the remaining screen fields. These values are most likely to change customer totals, tax, payment, fulfillment, and receivables.
-
Save the change, return to the list, and confirm that the return now appears under the expected Refund Status, and Edit Locked.
After the change: Confirm returned quantities, taxes, fees, tender, and Total Refunded before marking the refund complete.
Find and review returns
Use the Returns list to find the correct record before opening or changing it. Compare Date Created, and Refund Status. Records with similar names or numbers can still belong to different Sale, Customer, and Warehouse.
- The initial order emphasizes Id. Select a column heading when you need a different comparison.
Open the return whose Date Created, and Refund Status match the task. If it is missing, clear the list filters and recheck Refund Status, and Edit Locked rather than creating a replacement immediately.
Fields and business rules
Brisk stores 11 user-relevant fields for this return, including 3 linked-record selections and 1 controlled-choice field. Create and edit screens may hide calculated or workflow-managed values from this full reference.
| Field | Required | What it controls |
|---|---|---|
| Sale | No | Links this return to the selected sale; verify the relationship before saving. |
| Customer | No | Optional customer for ad-hoc returns. |
| Date Created | Yes | Date and time recorded for date created on this return. |
| Balance To Refund | Yes | The balance to refund value recorded for this return. |
| Tax To Refund | Yes | The tax to refund value recorded for this return. |
| Restocking Fee | No | The restocking fee value recorded for this return. |
| Total To Refund | No | The total to refund value recorded for this return. |
| Refund Status | No | The refund status recorded for this return. Available values: Complete, Pending, Draft. |
| Total Refunded | No | The total refunded value recorded for this return. |
| Edit Locked | No | Whether the edit locked option applies to this return. |
| Warehouse | No | Used for returns that are not linked to a sale. |
What happens next
Confirm returned quantities, taxes, fees, tender, and Total Refunded before marking the refund complete.
Common mistakes and troubleshooting
-
The record will not save: Recheck Date Created, Balance To Refund, and Tax To Refund and any message beside the field. A required related record may also be inactive or unavailable to your role.
-
The record saved but is not available where expected: Recheck Refund Status, and Edit Locked, then clear the filters on the destination list. A saved record can still be inactive, unpublished, locked, unapproved, or in the wrong workflow state.
-
The values look right but the result is wrong: Open Sale, Customer, and Warehouse from the detail page. Correct the specific relationship that is wrong instead of forcing a total or status to compensate for it.