Use Cases
These are the shapes the module is actually configured in. The examples use the wiki’s running example business, GadgetSphere Sdn Bhd — a Malaysian multi-branch consumer-electronics retailer with three companies and 22 branches across Klang Valley, Penang, Johor Bahru, Kota Kinabalu and Kuching.
1. Moving stock between two branches
The shape. GS-KV-03 is out of a popular accessory; GS-KV-01 has plenty. This is the most
common inventory operation in a multi-branch retailer and the one whose two-step shape surprises
people.
flowchart LR
REQ["Stock Requisition<br/>raised by GS-KV-03<br/><b>moves nothing</b>"] -.->|"optional, knocked off by"| OUT
OUT["Transfer Out<br/>at GS-KV-01"] -->|FINAL| Q["Transfer queue<br/><b>the in-transit record</b>"]
Q -->|"knocked off by"| IN["Transfer In<br/>at GS-KV-03"]
IN -->|FINAL| BAL["GS-KV-03 balance up<br/>GS-KV-01 balance already down"]
What to know:
- Between Transfer Out and Transfer In the goods are counted at neither location. That is what makes the queue a real in-transit record rather than a status field.
- A Stock Requisition moves nothing. It records the request. The movement is the transfer raised against it — from the transfer applet’s Search Document › Stock Requisition tab, or the CREATE ST button on the requisition.
- No value moves, and the company’s unit cost cannot change. Transfers carry quantity only and post no journal. But the per-location average is a different number: it seeds from the receiving location’s own history, so a branch that has never held the item values the arrival at zero. Use the company figure for valuation, never the branch one straight after a transfer.
- Transfers are same-company. Moving stock to another company in the group is a different document — see §5.
Watch for: the Details listing shows every outbound line with what has been received and what is outstanding. A queue that never empties is stock that has left one branch and arrived at none, and it will show up as a variance at both ends on the next count.
2. Keeping 22 branches stocked without anyone watching
The shape. Head office does not want to think about every accessory at every branch. Minimum and maximum levels are set per item per location, and the system raises the paperwork.
Two applets, and the difference matters:
| Stock Level Monitoring | Stock Replenishment | |
|---|---|---|
| What it does | Tells you. E-mails a list of people when quantity is below optimal or above maximum, per item category | Acts. Creates Purchase Orders or Outbound Stock Transfers |
| What it writes | Nothing | Order quantity and fulfilment lines, then documents |
| Shape | Template → event → run | Template → event → run |
Configure replenishment as:
- A template fixing the scope — items, locations, suppliers — and a fulfilment strategy: buy from a supplier, transfer from another location of the same company, or transfer from another company in the tenant.
- An event putting that template on a calendar, optionally recurring.
- A run, which computes how far each item × location is below its level and writes the lines. From those, Purchase Orders or Outbound Stock Transfers are created — by the screen, or by the processor itself for a scheduled event.
Watch for: the replenishment run is only as good as the min/max levels, and those are set per location. A new branch with no levels set is invisible to replenishment and to the min/max e-mail. Stock Level Monitoring uses its own per-category values instead, and checks only the locations on its template.
3. Counting the shelf and correcting the ledger
The shape. Quarterly full count at a branch, or a rolling weekly count of the fast-moving categories.
flowchart LR
S["Open a session<br/>one location"] --> D["Attach devices"]
D --> R["Capture records<br/>scan or type:<br/>item, qty, UOM, serial, batch"]
R --> REP["Generate the session report<br/>counted vs system,<br/>tolerance band, missing serials,<br/>cost of the difference"]
REP --> READ["A person reads it"]
READ --> ADJ["Stock Adjustment<br/>Adjust-In / Adjust-Out"]
ADJ -->|FINAL| BAL["Balance corrected<br/><b>and a journal posted</b>"]
What to know:
- The count changes nothing. There is no post-variance button. The session measures; the adjustment corrects.
- The tolerance band exists because the shop does not stop. Movements during the count widen the acceptable gap rather than being treated as errors.
- The report’s cost column is indicative. It values the variance at the location’s latest moving-average price; items with no history value at zero.
- An Android companion app writes to the same sessions and records through the same endpoints and adds an offline mode, which is what makes a full count in a back store practical.
Watch for: the adjustment is what hits the profit and loss account, so whoever raises it decides your shrinkage number. Restrict the finalise permission to supervisors and use a distinct GL code on the line for damage versus theft versus count variance.
4. Kitting — bundling items for a promotion
The shape. Ten single-pack accessories become one retail bundle for a campaign; after the campaign, the unsold bundles are broken back up.
Use Stock Conversion: one header at one location, Input lines and Output lines, saved as a draft and finalised.
Read the tabs literally, because they are the opposite of what a bill-of-materials tool means. Input = into stock. Output = out of stock. So to make bundles you put the components on Output and the bundle on Input.
And check that anything moved. The conversion’s stock step is not connected — no job is subscribed to its posting run — so a FINAL conversion leaves Stock Balance unchanged. Even once it is connected, no cost passes from the components to the bundle: the bundle arrives at its own last price at that location, zero for a new item. If the bundle must carry its components’ cost, record the build with Stock Adjustment, whose line amount does enter the moving average.
Stock Conversion is not a generic document — its own tables, its own posting endpoint, its own processors. There is no knock-off, no tax, no journal, no e-Invoice, and no VOID button in the user interface (VOID exists only through the API).
5. Consignment, in both directions
Two different situations that read alike and are not.
Your stock, somebody else’s shelf — a partner showroom, a dealer or a customer site. Use Consignee Stock Transfer. The destination is an ordinary location flagged as a consignee location. Each note is a single document: finalising it takes the quantity out of one location and puts it into the other in the same posting, so there is no in-transit queue. Quantity only; the stock stays on your balance sheet.
Somebody else’s stock, your shelf — a brand principal places stock with GadgetSphere and still
owns it until it sells. Use
Consignment GRN (Internal) to receive
it and Consignment GIN (Internal) to
send it back. The GRN does post a journal — CONSIGNMENT_STOCK against CONSIGNMENT_LIABILITY —
because the value has to be visible without being recorded as a purchase or a payable. The GIN posts
too, but through the ordinary purchase mapping (CREDITOR and PURCHASE), not the consignment
accounts, so a GRN and the GIN that returns it do not net off in the same two accounts. Ownership
changes later, when the goods sell and the consignment billing documents run.
A consignment GRN can be knocked off from a consignment purchase order and can be voided; the GIN can be neither.
6. Running an actual warehouse
The shape. The GadgetSphere Online fulfilment centre, where goods arrive by the pallet and leave by the parcel, and where a picker needs to be told which shelf.
The Warehouse Management System applet adds a physical layer under the documents:
| Inbound | Outbound |
|---|---|
| Receiving Doc — goods arriving, finalised on the listing | Picking Queue — order lines pushed in from the Sales Order applet |
| Processing Queue — created on finalise; where a container is allocated | Picking List — per-picker task lists, with a picking sequence and a cart |
| Putaway List and Putaway Processing — where the container goes | Packing List — packed and discarded product, then Doc Conversion |
| Scan Session — barcode over containers and spaces, through the browser camera | |
| Container Allocation — the map of container to layout node |
7. Trade-ins at the counter
A used phone taken against a new one is not inventory stock. It lives in its own tables, one row per serial per location, created automatically when the cash bill or sales document carrying the trade-in line is finalised, and reduced again when the unit is resold.
You will see it in Stock Availability, because that screen unions the two sets — and not in the historical stock balance report, because that one does not. Its value closes at month end through separate default GL codes. Look trade-in units up, correct them and attach documents in the Non Stock and Trade In applet.
What every one of these has in common
None of them is approved. No transfer, adjustment, conversion, count or consignment note routes to anybody, and the one inventory document the approval engine nominally covers — Stock Requisition — has no way to submit against a setting. Whoever holds the finalise permission acts, immediately. See Core concepts §7.