🔄 garment

Size Swap Requests

Size Swap Requests is a simple inter-branch workflow: when a customer wants a size or colour you do not have on the shelf, you log a request naming the product, size and quantity, optionally point it at a specific fulfilling branch, and track it through Pending, Approved, Shipped, Received or Rejected.

📍 Menu path: /garment/size-swap

👤 Who uses it: Owner,Manager,Staff

Overview

Every request stores a product (name, SKU, optionally linked to a real product record), the Size and Colour needed, a Quantity, a Fulfilling Branch (entered as a numeric store ID, not picked from a branch directory), and free-text Notes.

A five-stage status flow — PENDING, APPROVED, SHIPPED, RECEIVED, REJECTED — tracks the request from the moment it is raised to the moment stock physically arrives (or the request is turned down).

The page only shows requests relevant to the branch you are logged into: ones your branch raised, ones your branch has been asked to fulfil, or ones with no branch attached yet.

This screen is purely a request-and-status tracker — it does not itself move stock between branches. Confirming a request as Received records that the transfer happened; it does not adjust either branch's product quantities for you.

Before You Start

Requires the "inventory" plan feature to be enabled.
Product Name and Size are the only two required fields — SKU, Colour, Quantity, Fulfilling Branch and Notes can all be left blank when first raising a request.
There is no dropdown of your actual branch/store list for "From Branch" — you must know and type the numeric store ID of the branch you are requesting from.

Step-by-Step Guide

1 Request a size from another branch

Click New Request.
Type into Search Product to look up an existing product and auto-fill Product Name and SKU, or type the Product Name and SKU in manually.
Enter Size Needed * (required), Colour, Quantity (defaults to 1), and From Branch (ID) if you know which branch should fulfil it.
Add any Notes and click Send Request — this creates the record with status Pending.

2 Move a request through Approved → Shipped → Received

On a Pending request, click the coloured → APPROVED button once the fulfilling branch has confirmed stock.
Once shipped, click → SHIPPED, and once the item physically arrives at the requesting branch, click → RECEIVED.
Each click only advances the request one step at a time — the button always shows the single next status in the sequence, never lets you skip ahead.

💡 There is no "back" button in the UI — if a status is advanced by mistake, it can only be corrected via an API call to the update endpoint, not from this screen.

3 Reject a request

The Reject button only appears while a request is still Pending.
Click it to set the request's status to Rejected — once a request has moved to Approved or beyond, this screen no longer offers a way to reject it.

4 Filter and remove requests

Use the All / Pending / Approved / Shipped / Received / Rejected filter chips (each showing a live count) to narrow the list.
Click the trash icon on a row and confirm the browser dialog to permanently delete a request.

Every Field & Button, Explained

Field / Button	What it does
`New Request`	Opens the request form.
`Search Product`	Debounced (300ms) search against /products; selecting a result auto-fills Product Name and SKU.
`Product Name * / SKU`	Required product name plus optional SKU; can be typed manually instead of using search.
`Size Needed * / Colour`	Required size and optional colour the customer is asking for.
`Quantity`	Number of units needed; defaults to 1.
`From Branch (ID)`	A raw numeric store/branch ID for the branch expected to fulfil the request — there is no branch-name picker on this form.
`Notes`	Free-text notes on the request.
`Status filter chips`	All, Pending, Approved, Shipped, Received, Rejected — each shows a live count.
`Status badge`	Colour-coded per status: Pending (indigo), Approved (blue), Shipped (amber), Received (green), Rejected (red).
`→ Next-status button`	Advances Pending→Approved→Shipped→Received one step at a time; not shown once a request reaches Received or Rejected.
`Reject button`	Only shown on Pending requests; sets status to Rejected.
`Delete (trash) icon`	Permanently deletes the request after a confirmation prompt.

Tips & Best Practices

Double-check the numeric "From Branch (ID)" value before sending — there is no branch-name lookup on this form, so a typo silently routes the request to the wrong (or a nonexistent) branch with no error.
Use Notes to record anything the fulfilling branch needs to know (e.g. "customer waiting, please courier not post") since there is no other messaging channel attached to a request.
Once a request reaches Received, remember this page has not moved any stock for you — update each branch's product quantities separately (e.g. via Inventory or a stock transfer) to keep counts accurate.

Troubleshooting & FAQ

Why can't I reject a request that has already been Approved?

The Reject action only appears on Pending requests by design. Once a request has moved past Pending, this screen has no built-in way to reject it — you would need to handle the disagreement outside the app or update the status via the API directly.

I advanced a request to the wrong status by mistake — how do I undo it?

There is no back/undo button in the UI. The next-status button only ever moves a request forward one step. Reverting requires a direct PUT to /garment/size-swap-requests/:id with the earlier status.

I marked a request Received but the product's stock count didn't change at either branch.

That is expected — Size Swap Requests only tracks the status of the transfer conversation, it does not touch inventory quantities. You still need to record the actual stock movement (e.g. via Inventory/Stock Transfer) at both branches yourself.

The "From Branch" column just shows a number, not a branch name.

The field stores whatever numeric store ID was typed into "From Branch (ID)" at request time — there is currently no lookup against your actual branch/store list to resolve it to a name.

🧑‍💻 Developer Notes

Source component(s):

frontend-app/pos-app-garment/src/pages/garment/SizeSwapPage.jsx

Backend endpoints used:

GET /garment/size-swap-requests
POST /garment/size-swap-requests
PUT /garment/size-swap-requests/:id
DELETE /garment/size-swap-requests/:id

Related tables (db-core repositories):

SizeSwapRequest

Redux slices:

None — local component state only (useState/useCallback)

Feature flag key: inventory

listSizeSwapRequests (packages/pos-core/src/garment.js) scopes rows to the current store by matching requestingStoreId OR fulfillingStoreId OR a null requestingStoreId — so a request with no branch set is visible everywhere, which is intentional but easy to miss when auditing why a request shows up at an unexpected branch. updateSizeSwapRequest performs no status-transition validation server-side at all — any string can be PUT into `status` — so the strict Pending→Approved→Shipped→Received sequence and the Pending-only Reject rule are enforced purely by which buttons SizeSwapPage.jsx happens to render, not by the backend. There is no inventory/stock side effect anywhere in this flow — createSizeSwapRequest/updateSizeSwapRequest only ever touch the SizeSwapRequest row itself.