Multi-warehouse
Overview
Several warehouses with priority and their own stock valuation. The default warehouse handles stock resolution — it applies when no other one is specified.
Four levels build on one another: warehouse → bins → replenishment rules → stock. Stock per warehouse is read-only; postings arise through transfers and the posting routes of the other modules — never by typing a figure in.
Core tasks
Maintain warehouses. Priority and valuation per location; clicking the row opens the detail with bins, replenishment rules and stock.
Order the bins. Bins are sorted by picking sequence: pick priority ascending, then code. That sequence is the walking route in the warehouse — setting it sensibly saves steps on every pick.
Set replenishment rules. Min/max per product: if available stock falls below min, a suggestion arises to top up to max. There is exactly one rule per warehouse × product — so two contradictory rules cannot exist.
Consignment. Warehouses → Consignment shows what sits at the customer, what they consumed and which of it has not been invoiced yet. Three steps: see the stock at the customer (the work queue "consumed, not yet invoiced"), report consumption (product, quantity, optionally the customer's document reference) and mark as invoiced once the invoice has gone out. While the goods sit on the consignment shelf they are still ours — revenue only arises with the consumption report. To avoid ticking the loop back by hand, let an automation on the event consignment consumption reported do it.
Transfer. A transfer runs in three steps: create draft → send (outgoing) → receive (incoming). Between outgoing and incoming the goods are in transit and available in neither warehouse — exactly as reality has it.
Pick the shipping warehouse by proximity. Without a warehouse set on the order, Octibiz picks the warehouse by priority and stock: the default warehouse first, then the higher priority, and each only as far as stock is free there. With the switch Nearest warehouse first under Warehouse selection by proximity on, Octibiz instead orders the warehouses by straight-line distance to the recipient (delivery address of the order, otherwise billing address): the nearest warehouse with free stock reserves and ships first, the rest comes from the next one. Consignment warehouses stay at the back, warehouses without coordinates behind those with; at equal distance the previous order applies. This needs coordinates on the warehouses and an active geocoder (Settings → Integrations, type geocoder) that turns the recipient address into a location. If either is missing, the geocoder finds nothing or cannot be reached, the priority and stock rule applies silently — an order never gets stuck. A warehouse chosen on the order or delivery note always wins.
Outsource to the JTL Fulfillment Network. A fulfiller in the JTL Fulfillment Network is a fulfillment warehouse for us: the goods are ours, storage, picking and shipping happen there. For Octibiz to talk to the network itself, enter the warehouse ID in the network as Identifier at the provider and choose JTL Fulfillment Network under Fulfillment network. Set up the access under Settings → Integrations as type jtl_ffn. Octibiz then reconciles every 15 minutes (or right away with Reconcile with fulfiller at the top of the warehouses page):
- Products: stock-managed products with an SKU go into the network as merchant products (name,
SKU, EAN, manufacturer number, weight, country of origin); changed master data is sent again.
- Outbound orders: a released fulfillment order goes out with delivery address and lines; the
network's order number is then on the order (acknowledged).
- Shipping: when the network reports parcels, Octibiz adopts carrier and tracking number and
books the shipped quantities out of the fulfillment warehouse — partial deliveries included. An order cancelled in the network without shipment is withdrawn. If the fulfillment order comes from a sales order (reference sales_order:<record id>), a delivery note (shipped) and a shipment with the tracking number appear in the shipping center at the same time (fulfilment type Fulfiller), and the order moves on — without a second stock booking.
- Stock: stock per fulfiller warehouse arrives as an absolute report; the difference to our
books is booked as a stocktaking correction. Products with an order still running are reconciled by the next run after shipping — otherwise the goods would count twice.
Bookings go exclusively through the fulfillment orders and therefore through the inventory interface — never around the warehouse. Every run is in the integration's log.
Review suggestions across warehouses. The evaluation of all replenishment rules shows where topping up is due.
Stock at a glance. Warehouses → Stock matrix shows the available stock of every item in each active warehouse plus the total. A second number in brackets means part of it is reserved — the bracket gives the physical stock. Search and item condition narrow the matrix; with more than 50 items, a note below the table says how many are not shown.
Keep B-stock separate. Stock per warehouse is split by item condition: new, used/B-stock, refurbished and damaged each have their own line. A return books the goods in the condition you recorded on the return line — a used return therefore never lands in new stock. Only new goods can be sold on orders; replenishment rules, putaway suggestions and stock takes exist per condition (default: new goods): a rule for B-stock only watches B-stock, and a stock take counts each condition on its own line. Checked B-stock becomes new goods again via change condition; a channel listing with a condition reads exactly that stock. The distribution across bins also applies per condition: B-stock can only be placed on a bin as far as unplaced B-stock exists (state the condition when putting away).
Print the put-away list. On a warehouse detail page, Print put-away list prints the unplaced stock per item with the first bin suggestion and a column for the bin actually chosen — the work sheet for putting away without a scanner. The bin that was really used is still what gets booked.
See the stock value. The warehouse overview shows per warehouse the stock in units and the stock value in the book currency. How the value comes about depends on the warehouse's stock valuation: with Moving average it is quantity times average cost per item, with FIFO the sum of the purchase layers still open (remaining quantity times the layer's unit cost). A yellow badge next to the value gives the number of items without a known cost price — they are not counted, so the value is a lower bound, not a complete total. The warehouse's Stock tab shows the same figures as tiles (Stock value of this warehouse, Without cost price) and below them the unit cost per row according to this warehouse's method (column Avg. cost, in a FIFO warehouse the weighted cost of the open layers); "–" means unknown, not 0.00. The switch Without cost price only shows exactly the items that make up the gap — a purchase price or a receipt with a price is missing there. The tiles always cover the whole warehouse, even when the list is filtered; zero stock is not a gap.
Fields in detail
Brand (brandId) of the warehouse: lists and pickers show it only within that brand, empty = all brands; stock inherits the brand. When receiving a stock transfer (receivedItems) you can enter the quantity that actually arrived per item; without it everything counts as shipped, and a difference remains visible as a shortfall.
The What it does column answers what changes in the system — not what the field is called. The grey name behind the label is the API field: the same thing runs under that name through automation, import and AI tools.
Creating and editing a warehouse
| Field | Required | Values / format | What it does |
|---|---|---|---|
Code code | yes | text, max. 30 characters | The warehouse identifier in bookings, labels and reports. Do not change it once stock lies on it. |
Name name | yes | text, max. 100 characters | What the warehouse is called in selection and overview. |
Warehouse type type | no | own warehouse (default), consignment or fulfilment warehouse | Who owns the warehouse and who books in it. A consignment warehouse keeps our goods at the customer's site: putting them in is a transfer without revenue, only consumption is invoiced. A fulfilment warehouse keeps our goods in someone else's operation: they pick for us, and stock arrives as their report, not from a booking of ours. |
Consignment customer partnerCustomerId | with consignment | an existing customer | Whose site the warehouse sits at. Without it a consumption report would not know who to bill. |
Operating service provider partnerSupplierId | no | an existing supplier | Who runs the fulfilment warehouse. Optional: what makes such a warehouse are its reports, not a master record. |
Identifier at the provider externalCode | no | text, max. 60 characters | The identifier the provider keeps this warehouse under. They know us by their number, not by our code — without it their reports cannot be matched. |
Fulfillment network fulfillmentNetwork | no | none (default) or JTL Fulfillment Network (jtl_ffn); only on a fulfillment warehouse with identifier | Whether Octibiz itself exchanges products, orders, shipments and stock with the network. The identifier at the provider is then the warehouse ID in the network. Without it, reports come by hand, as a file or via a flow. If the warehouse type changes, the connection is dropped. |
Default isDefault | no | yes/no | Which warehouse is chosen when nothing else is stated. There is exactly one; the mark moves. |
Priority priority | no | number | In what order warehouses are drawn on for reservation and shipping when no warehouse is given. A higher number means earlier; the default warehouse always comes first. With selection by proximity it only breaks a tie in distance. |
Latitude latitude | no | decimal degrees −90 to 90, only together with longitude | Where the warehouse is — the basis of selection by proximity. Without coordinates the warehouse takes no part in it and stands behind the warehouses with coordinates. |
Longitude longitude | no | decimal degrees −180 to 180, only together with latitude | Counterpart to latitude. Half an entry is rejected — a latitude alone is not a location. |
Valuation method valuationMethod | no | FIFO or average | How the stock value is calculated. FIFO values by order of receipt, average by moving mean. Switching the method later changes the reported stock value — it is an accounting decision, not a setting. |
Active active | no | yes/no | Off means no new bookings. Existing stock stays visible and must be transferred out first. |
Stock transfer
| Field | Required | Values / format | What it does |
|---|---|---|---|
From warehouse fromWarehouseUlid | yes | an existing warehouse | Where the goods come from. |
To warehouse toWarehouseUlid | yes | an existing warehouse | Where they go. |
Items items | yes | articles with quantity | What is transferred. More than is present cannot be booked. |
Note note | no | text | Why the transfer is made. |
A transfer has two stages: the outgoing side is booked, the goods count as in transit, and only the incoming side credits them to the target warehouse. In between they are available nowhere — that is intended and mirrors reality instead of doubling stock.
Replenishment rule
| Field | Required | Values / format | What it does |
|---|---|---|---|
Article productId | yes | stock-managed article | Which article is monitored. |
Minimum minQty | yes | whole number | If the available stock falls below it, a suggestion appears. |
Maximum maxQty | yes | whole number, at least the minimum | Up to where stock is topped up. |
Source warehouse sourceWarehouseId | no | another warehouse | Where the transfer comes from; empty means reordering. |
Target bin targetBinId | no | bin of the warehouse | With a bin, the rule watches this pick bin and suggests replenishment from reserve; without, it applies to the whole warehouse. |
Source bin sourceBinId | no | reserve bin of the warehouse | Fixed reserve bin for replenishment; empty means the reserve bin with the most stock. |
Condition condition | no | new (default), used/B-stock, refurbished, damaged | Which stock the rule watches. B-stock never covers a new-goods minimum; there is one rule per condition. |
On the Replenishment rules tab each rule's condition has its own column; in the dialog you choose it when creating and when editing (default new goods).
Interface and automation only
No mask carries these fields; they can be set through the interface, an import or an automation.
| Field | Values / format | What it does |
|---|---|---|
singleProductBins | yes/no (default: no) | Single-product bins: a bin holds at most one article. Placing stock into a bin that already holds a different article is rejected. Whoever stores single-product picks blind — a second article in the bin becomes an unnoticed mispick. Off means mixed bins are allowed. |
putawayTargetRequired | yes/no (default: no) | Mandatory target bin: a receipt without a bin is rejected. Unplaced quantity is stock the books know about and nobody can find. Off means unplaced quantity stays allowed. |
autoPutawayToDefaultBin | yes/no (default: no) | Receipts without a bin land on the default bin of the article instead of staying unplaced. Without a maintained default bin nothing changes. |
putawayStrategy | free location, name ascending/descending, sort ascending/descending (default: sort ascending) | The order in which free locations are proposed when putting away. Free location fills gaps, the name strategies walk the aisle systematically. Deliberately here rather than in the create dialog: it is one of four putaway switches, and the three above belong just as little in a mask where a warehouse is first created. |
address | address as structured data (street, postcode, city, country) | Where the warehouse is. Proposed as the delivery address for orders. |
clearCoordinates | yes | Removes latitude and longitude of the warehouse; it then no longer takes part in selection by proximity. In the form, emptying both fields is enough. |
Settings & permissions
- Module
module.warehouses. warehouses.warehouse.view/.manage,warehouses.stock.view/.manage,
warehouses.transfer.manage.
- Stock value: column Stock value in the overview with
warehouses.warehouse.manage, tiles and
unit cost in the Stock tab with warehouses.stock.view; API GET /api/v1/warehouses/{ulid}/stock-value (filter onlyUnvalued) and the warehouse list with withTotals=1.
- Selection by proximity: switch
warehouses.allocation.proximity(default off) under
Warehouse selection by proximity on the warehouses page, with platform.settings.manage. The geocoder is an integration of type geocoder with the address url of a service with a Nominatim interface (recommended: self-hosted); a service with an account gets its key as api_key (stored encrypted) and if needed the parameter name api_key_param (default key). Switching off = set the integration to inactive. The recipient address leaves the system only towards this service; hits are remembered for 30 days.
- JTL Fulfillment Network: integration of type
jtl_ffn(across brands). Settings:environment
(sandbox as default or production), optional base_url, token_url (default https://oauth2.api.jtl-software.com/token), scope (default ffn.merchant.read ffn.merchant.write) and shipping_type (shipping type of the orders, default Standard). Secrets (encrypted): client_id, client_secret and the refresh token refresh_token from the authorisation in the JTL account; Octibiz stores a newly issued refresh token itself. The connection check only exchanges the token. On-demand reconciliation with warehouses.fulfillment.manage (POST /api/v1/warehouses/fulfillment-network-sync), otherwise every 15 minutes. Switching off = set the integration to inactive or remove the connection on the warehouse.
- Total stock lives in the product catalogue — its distribution lives here.
- Purchasing triggers no transfer. Lines from another warehouse are rejected there, see
FAQ & troubleshooting
Stock in a warehouse cannot be changed. By design — it is read-only. Post through a transfer or the respective module's route.
After sending, the goods are missing everywhere. They are in transit. Only receiving posts them at the destination.
No replenishment suggestion appears. Check whether a rule exists for that warehouse and product, and whether available stock really falls below min.
The reconciliation with the fulfiller reports "nothing requested". The access is missing (integration jtl_ffn active with client ID, client secret and refresh token) or an active fulfillment warehouse with identifier and fulfillment network. If sign-in fails, the integration's connection check says so — then issue a new refresh token in the JTL account.
Selection by proximity does not take effect. Check the switch Nearest warehouse first, the coordinates of the warehouses, whether the geocoder is active (its connection check under Settings → Integrations) and whether the order carries an address with postcode or city. If anything is missing, the priority and stock rule applies on purpose.
Two rules for the same product. There are none — exactly one rule per warehouse and product is possible.
A product appears twice in the stock list. It exists in two conditions, for example as new goods and as B-stock. The Condition column shows which line is which; the Condition filter shows only one of them.
The condition of a restocked return line cannot be changed. By design: the goods already sit in the stock of the old condition. First change the disposition (the goods leave stock again), then change the condition and restock.