Written guide
Overview
Handle returned goods and refunded money as connected but separate decisions, using the original order and its saved references.
Before you start
Decide whether you are handling goods, money, or both. A damaged physical item needs an RMA/inspection decision; a delivery-charge concession may be money-only. A refund does not automatically create a physical return or add stock.
| Record | What it answers |
|---|---|
| Original order/payment | What was bought and collected? |
| Return/RMA | Which goods were requested, received and accepted? |
| Refund record or provider reference | Which money movement actually happened? |
| Return stock decision | Which accepted goods can return to the original location? |
The illustrated local example below is a $5 delivery-charge refund on gift-card order GKEJ9KIXU; it is not a completed physical RMA. The current RMA procedures are documented, but an Appmint end-to-end physical-return capture remains pending.
01. Inspect the original sale and RMA
Why this matters
An RMA identifies the goods being returned. Payment and stock information come from the original sale.
Follow these steps
Open the supported paid catalogue order and the corresponding Return record. Verify order number, customer, SKU, return quantity, condition and reason. In Returns & RMA → Returns inspect the available approval/rejection action. On approval enter the return address and approval notes where shown; for rejection enter a reason.
Check the result
Do not invent a universal New Return button if the actual return originates from an order/customer route. A free-text invoice line may have no stock snapshot.
Find the return before changing its state
- Open Storefront → Return → Returns.
- Use Search by RMA, order, or customer… and review All Types/All Statuses if an expected record is hidden.
- Open the matching RMA and compare its original order, SKU and quantity. Do not manufacture a new return simply because a money-only refund has no RMA.
This historical empty state is not a completed return. It distinguishes the physical-return list from order payment/refund activity.
- If no return exists, follow the actual customer/order return-request route for that installation. The captured staff list has no universal New Return button; do not treat this course as evidence that such a control exists.
02. Receive and inspect goods
Why this matters
Receiving does not automatically refund or restock. Inspection decides which returned items are accepted.
Follow these steps
On an approved return choose Receive return in store when physically handed to staff, then inspect each item. Use the per-item Accept/Reject decision and record the condition/notes. Reopen Return Details to inspect accepted quantities and return status. Use the Shipping Label section only for a label actually generated through a configured provider.
Check the result
A carrier label is not evidence the goods arrived. Damaged items must not be treated as fit for resale.
03. Record the monetary outcome
Why this matters
The return completion form records an actual refund reference; it does not silently call an external gateway.
Follow these steps
Process the supported refund through the original payment workflow first when required. In return completion enter Refund amount, Refund method and the saved refund-record IDs or external reference. Methods include Original payment, Store credit, Exchange and Gift card. For cash, first record the handout in POS and copy the saved Refunds record ID; separate multiple IDs with commas. Confirm and inspect the Completion record and original payment/refund records.
Check the result
Positive amounts require a reference. External references are recorded without provider verification. Store credit and Gift card can issue stored value, so selecting them is a financial action, not a harmless label.
Money-only example: refund the delivery charge
- Open the original order and Payments. Confirm the original collection and existing refunds first.
- Open Actions, scroll to Refund, enter the intended amount and a specific reason. In the historical example the amount is
5and the reason identifies the delivery-charge concession.
Historical pre-submit refund on GKEJ9KIXU. This is an actual money action, not a preview or RMA approval.
- Choose Process Refund once and wait for its result. Reopen Payments and compare original collection, cumulative refund and retained amount; if the response is unclear, inspect records before retrying.
- For the gift-card tender used here, inspect the card's credit movement linked to the same order. For an external provider, verify its own refund reference; this local gift-card example does not prove external settlement.
- Leave physical inventory unchanged for a delivery-only concession. There are no returned print units in this example.
Historical result: gross collected $30, refunded $5, retained $25 and uncollected $0. A partial refund does not mean another $5 is due from the customer.
RMA completion is a different handoff: use the actual saved monetary reference when completing a physical return. Do not enter a made-up reference merely to satisfy the form or repeat the refund to create one.
04. Decide stock at the original location
Why this matters
The stock decision adds only accepted sellable units and reverses their original cost; it does not refund money.
Follow these steps
On a completed return choose Return stock decision. Inspect the original sale location and accepted SKUs/quantities. Choose Fit for resale or Damaged — do not restock. Select Restock for the sellable quantity or Record damaged return. Inspect the saved result, location quantity and cost movement.
Check the result
The dialog requires a completed stock-cost snapshot on the original sale. If missing, no stock changes: resolve the original cost before proceeding. Retry stock decision completes a saved incomplete decision without adding units twice; Reload saved decisions before retrying after an unclear result.
05. Reconcile full, partial and failed outcomes
Why this matters
A full refund, partial refund and stock-only decision leave different evidence.
Follow these steps
Compare the original paid amount, cumulative refunds, remaining refundable amount and customer evidence. Inspect returned quantity and stock movement separately. Reopen the RMA, payment and inventory records after a reload. For money-only cases leave physical stock unchanged; for damaged returns record the damage without sellable stock.
Check the result
Do not duplicate a refund to make a dashboard agree. Verify the original operation and report discrepancies with its order, RMA and refund references.
Detailed instructions
The following retained material documents earlier local work. Its pending checks remain pending; historical successful outcomes are not claims of a fresh execution. Use the source-authored instructions above to prepare the new recording, and preserve these references for comparison.
A16: Receive a return and decide its condition
Learner draft — pending demonstration:
A returned print raises two questions: can the shop sell it again, and should the customer receive money back? Start with the original order and line. Inspect the returned item, then choose the supported stock treatment for sellable or damaged goods. The original location and cost history matter for reconciliation. A manual invoice line without a catalogue stock link is not a substitute for that history.
Included controls: Dashboard, Returns, Manage, return request, original order/line, inspection, sellable restock, damaged goods, origin stock/cost, return label, history.
Limitations and checks: E18 paid/stock-settled order prerequisite. Exact request/receive/inspect/restock controls, sellable/damaged comparisons, original cost/location guard, labels/history. Capture cannot-return boundary when stock snapshot absent.
Check the result: Return linked to original catalogue line; sellable balance changes correctly/damaged does not silently restock.
Implementation reference: return-stock-dialog.tsx, return-content.tsx.
A17: Refund money independently of stock
Worked example
A refund changes money; it doesn't put the print back into stock. We'll give this buyer a five-dollar delivery concession. Open the same order, check Payments, then Actions. Enter five in refund Amount, explain the concession in Reason and choose Process Refund. Reopen Payments after the confirmation. Thirty was collected, five refunded and twenty-five retained; the original gift-card payment remains below. Now open that card in Gift Card Center. Its balance rises from twenty to twenty-five, and the timeline links the refund to our order. The order and original tender agree on where the money went.
Included controls: Refunds, full/partial refund, provider rejection, stock-only return, money-only refund, both, refund reconciliation.
Limitations and checks: Full refund, stock return and provider rejection are separate unfinished branches. The reason is a delivery concession, not proof of refund allocation to financial lines or a carrier refund. Home revenue0 is current UX09, not corrected analytics; do not narrate dashboard success here.
Check the result: GKEJ9KIXU order Payments30gross/5refunded/25net, originalGCT-TM5H-Y4SW-Q677 preserved, +5card refundGCT-PWBV-3D8C-LMW4 linked same order.
Implementation reference: refund-list.tsx, storefront.payment.service.ts.
Next-batch matching evidence: SF48-partial-refund.webm.
Limitations and checks
Current UI entry and editor: . Corresponding SDK storefront schemas and the retained AppEngine references define fields and consumer boundaries. Provider calls, external delivery, payments and financial mutations were not performed for this writing task.
Next steps
You can now follow the module from its configuration to the record that proves the result. Use the relevant chapter to revisit an alternative or troubleshoot the exact failed handoff.
BusinessMade Returns — supporting guide
Reader update: BusinessMade route and current mounted source reviewed 5 October 2026.
Understand the records and results
Explanatory diagram, not an application screenshot. A received item does not prove a refund; a refund does not prove a stock increase. It explains the distinctions used in the steps below; it does not establish a completed live workflow.
Prepare a traceable return
Have the original paid order reference, customer, item SKU and quantity available before opening Storefront → Returns. Use Returns for the goods/RMA record and Refunds for the money record. The two tabs answer different questions: whether the goods were accepted and whether money was returned.
The retained BusinessMade dashboard image was inspected but not used as an example of healthy results: it displays NaN for In Progress. Another purported Returns capture is only a sign-in page. Do not translate an invalid metric into “no returns”, or use a dashboard total to decide which item to refund.
After receiving and inspecting, reopen the same return and compare accepted quantity and status. Then check the linked refund record independently, including original payment reference and provider outcome. Restock only the accepted units under the actual supported action. A carrier label, accepted item and completed refund are three separate results.
Overview
Handle returned goods and refunded money as connected but separate decisions, using the original order and its saved references.
BusinessMade entry and scope
Open Storefront → Returns at /storefront/returns in BusinessMade. This route mounts the shared Returns module; the surrounding menus are BusinessMade’s. Use Operations → Contacts for customer details, Operations → Customers & Benefits for group eligibility, Admin → Business locations for branches, and Operations → POS / Order entry for counter sales. Keep the organization and record identity consistent across those screens.
The location selector governs the venue-specific POS, but does not establish that every shared Storefront module filters its data by that selection. Inspect the record’s own location and currency. Payments are under Storefront → Payments, while delivery rules and shipments are under Storefront → Shipping; creating this module’s record is not payment or shipping-provider configuration.
01. Inspect the original sale and RMA
Context
An RMA identifies the goods being returned. Payment and stock information come from the original sale.
Follow the steps
Open the supported paid catalogue order and the corresponding Return record. Verify order number, customer, SKU, return quantity, condition and reason. In Returns & RMA → Returns inspect the available approval/rejection action. On approval enter the return address and approval notes where shown; for rejection enter a reason.
Check the result
Do not invent a universal New Return button if the actual return originates from an order/customer route. A free-text invoice line may have no stock snapshot.
02. Receive and inspect goods
Context
Receiving does not automatically refund or restock. Inspection decides which returned items are accepted.
Follow the steps
On an approved return choose Receive return in store when physically handed to staff, then inspect each item. Use the per-item Accept/Reject decision and record the condition/notes. Reopen Return Details to inspect accepted quantities and return status. Use the Shipping Label section only for a label actually generated through a configured provider.
Check the result
A carrier label is not evidence the goods arrived. Damaged items must not be treated as fit for resale.
03. Record the monetary outcome
Concept diagram, not a screenshot or a completed-action record. Neither branch completes the other. Check both against the same original sale.
Context
The return completion form records an actual refund reference; it does not silently call an external gateway.
Follow the steps
Process the supported refund through the original payment workflow first when required. In return completion enter Refund amount, Refund method and the saved refund-record IDs or external reference. Methods include Original payment, Store credit, Exchange and Gift card. For cash, first record the handout in POS and copy the saved Refunds record ID; separate multiple IDs with commas. Confirm and inspect the Completion record and original payment/refund records.
Check the result
Positive amounts require a reference. External references are recorded without provider verification. Store credit and Gift card can issue stored value, so selecting them is a financial action, not a harmless label.
04. Decide stock at the original location
Context
The stock decision adds only accepted sellable units and reverses their original cost; it does not refund money.
Follow the steps
On a completed return choose Return stock decision. Inspect the original sale location and accepted SKUs/quantities. Choose Fit for resale or Damaged — do not restock. Select Restock for the sellable quantity or Record damaged return. Inspect the saved result, location quantity and cost movement.
Check the result
The dialog requires a completed stock-cost snapshot on the original sale. If missing, no stock changes: resolve the original cost before proceeding. Retry stock decision completes a saved incomplete decision without adding units twice; Reload saved decisions before retrying after an unclear result.
05. Reconcile full, partial and failed outcomes
Context
A full refund, partial refund and stock-only decision leave different evidence.
Follow the steps
Compare the original paid amount, cumulative refunds, remaining refundable amount and customer evidence. Inspect returned quantity and stock movement separately. Reopen the RMA, payment and inventory records after a reload. For money-only cases leave physical stock unchanged; for damaged returns record the damage without sellable stock.
Check the result
Do not duplicate a refund to make a dashboard agree. Verify the original operation and report discrepancies with its order, RMA and refund references.
BusinessMade operational handoff — Refund a counter tender and decide stock separately
Context
Returns connects to the saved customer, product or transaction. Follow that identity through the BusinessMade operation rather than creating a second record to illustrate a result.
Follow the steps
Open the original POS tab at its location and inspect the actual paid tender and refundable amount in Settle. Use its refund control with the intended amount and reason. Cash records money returned; card and gift-card branches call their respective refund path. Inspect the result, including any retry-records status, and retain its reference. Open Storefront → Returns and use the original order/RMA; do not refund the same value again while recording completion. After accepted items and refund accounting, choose Return stock decision. Compare the original POS inventory snapshot and source location. Mark fit-for-resale or damaged, submit once, then inspect stock and the saved decision.
Recovery and implementation boundary
Completing an RMA does not itself charge an external refund. POS original-payment refunds and return stock decisions are distinct. A failed journal/record step after a provider refund must not trigger a second provider refund.
Limitations and checks
Substantive pending work: Completing an RMA does not itself charge an external refund. POS original-payment refunds and return stock decisions are distinct. A failed journal/record step after a provider refund must not trigger a second provider refund. Runtime evidence for the taught handoff remains separate from authored coverage. Do not mark the course production-ready until the intended branch’s saved result, failure recovery and customer/provider outcome have been checked.
Next steps
You can return directly to the chapter for the change you need. Keep the saved record and its operational result together: the same customer, product, location and transaction should remain identifiable through each handoff.