Step-by-step instructions
A manager can create a stock transfer that decreases the correct source warehouse, increases the correct destination warehouse, explains why the movement happened, and remains reliable for stock history, reports, support, and future AI agents.
Use the interactive screenshot walkthrough first. Switch steps with the step dots, then read what to fill and why it matters.
Fields on this screen
Transfer list
How to fill: Open Transfer and check existing rows before creating a new transfer.
Why: Duplicate transfers can double move stock and confuse inventory reconciliation.
Product transfer form
How to fill: Open the Product transfer form only after the Transfer list has loaded.
Why: The form relies on app state for warehouses, reasons, and products.
Transfer date
How to fill: Confirm the movement date and time.
Why: Inventory history and audit reports depend on the correct movement date.
Reason for transfer
How to fill: Select a reason such as Internal transfer.
Why: The reason explains why stock moved and prevents the row from looking like a hidden correction.
From warehouse
How to fill: Choose the warehouse where stock currently exists.
Why: This is the location that will decrease.
To warehouse
How to fill: Choose the warehouse that should receive the stock.
Why: This is the location that will increase.
Comment
How to fill: Write a short note with the operational context.
Why: The comment helps managers understand the transfer without opening item details.
Select product
How to fill: Open Select product, search by product or ingredient name, and select the exact row.
Why: Only real product rows can update stock correctly.
Specification / variant
How to fill: Use the optional selector only when the product has variants or specifications.
Why: Leaving it empty is correct for a simple ingredient with no variants.
Order type
How to fill: Open Order type only if the movement is connected to a specific order or deduction context.
Why: Random order type values make reports and explanations misleading.
Gross
How to fill: Enter the quantity being moved before losses or adjustments.
Why: Gross records the physical amount leaving the source warehouse.
Net
How to fill: Enter the quantity expected at the destination warehouse.
Why: For normal internal movement, Net should match Gross.
Add line
How to fill: Click Add after product, quantity, and optional fields are correct.
Why: The selected product is not part of the transfer until it is added as a line.
Save
How to fill: Save after reason, warehouses, comment, and all item lines are checked.
Why: Only saved transfer documents become reliable stock history.
Verify row
How to fill: Return to the Transfer list and verify date, type, warehouse, reason, contents, and comment.
Why: Verification proves the row was written and loaded back from the real database.
Common mistakes
- Creating a transfer before the Transfer list has loaded app state for warehouses, products, and reasons.
- Choosing the same warehouse as source and destination.
- Reversing From warehouse and To warehouse.
- Saving without adding product lines.
- Selecting a product with a similar name instead of searching and confirming the exact row.
- Typing quantity in the wrong product unit.
- Using different Gross and Net values without an actual loss, shrinkage, or adjustment reason.
- Choosing Order type randomly when the transfer is not connected to an order context.
- Treating a transfer as a supplier supply, sale, write-off, or finance payment.
- Editing write_offs directly in Supabase without refreshing loadwriteoff, loadstorage, and loadproduct.
AI Agent Field Reference for implementation
This block is intentionally below the human instructions. It explains storage names and downstream dependencies for automation, support, and future AI agents.
| Field | Stored as | Purpose | Why it matters |
|---|---|---|---|
| Transfer ID | write_offs.id / WriteOffStruct.ID | Unique transfer document identifier. | Stock history, support, reports, audit, and AI agents need a stable transfer ID. |
| Transfer type | write_offs.type = "=" | Document type marker used by the Transfer list. | Transfer rows are stored in write_offs and filtered by type "=", so agents must not confuse them with write-offs. |
| Company | write_offs.company | Company workspace that owns the transfer. | Prevents warehouse movements from one workspace from appearing in another company. |
| Transfer date | write_offs.date / WriteOffStruct.Date | Date and time of the warehouse movement. | Stock history, inventory audit, reports, and shift review depend on the correct date. |
| Reason | write_offs.reasons / WriteOffStruct.Reasons | Reason object selected from write_off_reasons. | Explains why stock moved and gives support or AI agents context for the transfer. |
| Comment | write_offs.comment | Short operational note. | Comments explain the practical reason, destination shelf, manager instruction, or exception. |
| From warehouse | write_offs.storage | Source storage ID. | This is the warehouse whose stock decreases. |
| To warehouse | write_offs.to_storage | Destination storage reference saved as text with generated destination ID and storage ID. | This identifies where stock should appear after the transfer. |
| Items | write_offs.items[] / WriteOffStruct.Items[] | List of product movement lines. | A transfer is only meaningful when each moved product is added as a line item. |
| Item ID | write_offs.items[].ID | Unique movement line ID. | Line IDs let support, imports, audits, and AI explanations refer to a concrete product movement. |
| Item date | write_offs.items[].date | Date stored on the movement line. | Keeps product movement history aligned with the transfer document date. |
| Item movement type | write_offs.items[].Type = - | Movement direction stored for the source-side inventory operation. | The transfer function writes outgoing movement lines and destination storage metadata. |
| Product | write_offs.items[].Product | Product or ingredient ID being transferred. | This is the actual stock item that leaves one warehouse and arrives in another. |
| Specification / variant | write_offs.items[].specifications | Optional product specification, packaging, or variant IDs. | Use it only when the product has controlled variants; otherwise leave it empty. |
| Gross quantity | write_offs.items[].Gross | Quantity before losses or adjustments. | For a clean transfer, Gross usually equals Net. |
| Net quantity | write_offs.items[].Net | Quantity that should arrive at the destination warehouse. | Net is what managers expect to find at the receiving storage location. |
| Unit | products.unit_of_measurement | Measurement unit shown for the selected product, such as kg, pcs, or l. | Quantity without unit is ambiguous for staff, reports, and AI agents. |
| Order type | write_offs.items[].typeorders | Optional order or deduction context. | Use it only when the transfer is connected to a specific operational order type. |
| Item storage | write_offs.items[].Storage | Destination storage ID written on the movement line. | Connects the product line to the receiving warehouse. |
| Line reason | write_offs.items[].Reasion | Reason ID copied onto the line when used. | Lets item-level analysis preserve the reason even when lines are inspected separately. |
| Line comment | write_offs.items[].Comment | Generated or typed item note. | Clarifies destination or special handling for the line. |
| Amount / price fields | write_offs.amount / items[].Price / items[].amount | Usually zero for a pure warehouse transfer. | Transfers move stock; they should not be treated as supplier cost, sale revenue, or finance transaction by default. |
| Created at | write_offs.created_at | Timestamp when the row was written. | Useful for setup troubleshooting and audit history. |
| User | write_offs.user | User who created or owns the transfer when present. | Supports responsibility and audit review. |
| App transfer cache | FFAppState().Writeoff filtered by type "=" | Client-side list used by the Transfer table. | After native backend edits, the app must reload write-offs before the list shows current transfer rows. |
| Reload markers | company.loadwriteoff / loadstorage / loadproduct | Company timestamps used to refresh transfer, warehouse, and product data. | Backend and native changes need these markers so forms and lists see current records. |
Related guides
Use these guides to connect this section to adjacent SABSUS workflows.