Returns span two workspaces — the Returns module (the customer’s request) and the Warehouse Returns workspace (the physical units). This page covers the blocks and errors in both, including the ones that are deliberate (features awaiting platform activation) so you don’t fight them.
How to read this page
Match your exact message to a card. A recurring theme here: several return actions are gated platform-side today — the card tells you which ones work now, and what to do meanwhile. Code-only lookup: error code index.
Warehouse-return decisions not enabled
FEATURE_DISABLEDTransfer to FBF / Return to me / Keep stored are blockedChoosing any decision other than Dispose in Warehouse Returns shows the toast «هذا الإجراء غير مفعّل بعد — قريباً.» / “This action isn’t enabled yet — coming soon.”
- Seller return-decisions (other than Dispose) are awaiting platform activation — the server answers with the
FEATURE_DISABLEDcode by design.
- Dispose works today if disposal is genuinely what you want (a reason is required; success shows «تمت إضافة الإتلاف إلى قائمة المستودع.» / “Disposal queued for the warehouse team.”).
- Otherwise wait — your units stay safely stored and nothing is lost by waiting.
- Storage continues while units remain stored. The financial details of this step are covered in a dedicated Finance guide coming soon.
If a case is urgent (e.g. perishable or high-value stock), open a support ticket (Returns & refunds) and include the case ID from the Warehouse Returns page.
Do not choose Dispose just because it is the only enabled button — disposal is irreversible.
Read-only returns
“This return is not managed by the seller” («هذا المرتجع لا يديره البائع») with a Read Only chip and no action buttons.
- The return belongs to an FBF or MARKET order — Fawran manages the request, inspection and refund. Only FBS returns are seller-actionable.
- Nothing to action in the Returns module — this is by design.
- Watch the Warehouse Returns workspace instead: if the physical units end up there, the disposition decision (what happens to the goods) is where you come back in.
Only if you believe the return was misclassified — ticket with the return ID.
FBS return form errors
“Explanation must be at least 20 characters” («الشرح يجب أن يكون على الأقل 20 حرف») when rejecting an FBS return.
- A rejection is reviewed by the support team, so a substantive reason is mandatory — the note field requires at least 20 characters.
- Pick the closest rejection reason from the list.
- Write a factual explanation of at least 20 characters (what you inspected, why the claim does not hold).
- Confirm the rejection.
SLA countdowns and expiry
The countdown chip on an FBS return turns red and then shows expired.
- Each FBS return stage has a deadline: 48 hours for the initial response, the review stage and the shipping-in-progress stage; 24 hours for the other stages.
- The stage action was not taken in time.
- Act now — an expired timer does not remove your action buttons; the longer it stays red, the worse for your performance record and the more likely platform intervention.
- Prioritize returns from the warning state (yellow) before they expire — the list shows near-deadline counts.
If you could not act because a button errored (not because of time), report that specific error with a screenshot and the return ID.
Dispute evidence
You attach images to a dispute (up to 5) and they preview fine, but they may not reach the review team.
- Evidence upload in the dispute form is not fully wired yet — image persistence is still being completed platform-side.
- Submit the dispute with its written reason and description as usual.
- Then open a support ticket (Returns & refunds) and attach the same images there — tickets accept up to 5 attachments of 10MB each and are reliably stored.
- Reference the return ID in the ticket so the two are linked.
This IS the escalation — the ticket is currently the dependable evidence channel.
Unit identity problems
A warehouse-return case shows an identity problem on a unit — e.g. the returned unit’s code does not match any unit sold for that order, or the same unit code appears twice.
- Every unit carries a permanent identity code (shaped like
FWU-2026-000000000123-C7) bound at warehouse receipt; the platform validates returned units against it. - The buyer returned a different physical unit than the one delivered, or a unit was scanned twice.
- You do not resolve the scan yourself — the warehouse opens a case for the mismatched unit.
- Follow the case in your Inventory cases/Warehouse Returns view and respond to any decision it asks of you.
If you believe the flag is wrong (e.g. you can prove the unit is yours), open a ticket with the case ID, the unit code and your evidence.
Return stuck at a stage
Who moves next depends on the surface:
| Where | Stuck state | Whose move |
|---|---|---|
| Returns module (FBS) | Any stage 1–11 | Yours — advance the stage or the timer runs down. |
| Returns module (FBF/MARKET) | Any | Fawran’s — read-only for you. |
| Warehouse Returns | «بانتظار الفحص» (pending inspection) | The warehouse inspects first; decisions unlock only when the case is inspected and pending decision. |
| Warehouse Returns | «بانتظار القرار» (pending decision) | Yours — but non-Dispose decisions are awaiting platform activation (see the first card). |
Before you contact support
- The return ID or warehouse-return case ID.
- The exact message or the stage where things stopped.
- Unit codes if the problem is unit-level (
FWU-…). - Photos/screenshots — attach them to the ticket, especially for disputes.