> For the complete documentation index, see [llms.txt](https://docs.flowretail.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flowretail.com/docs/advanced-features/inter-store-trade.md).
# Inter-store trade
The Inter-store trade extension is perfect for professional retailers with multiple stores and one (or even multiple) central warehouse(s).
Let the stores order goods from your central warehouse, or allow for goods directly between shops.
**One store's purchase order is another store's sales order.** Inter-store trade keeps the two in step, so goods move between your own stores on the same machinery you already use for buying and selling.
## What it is for
Most chains buy centrally and sell locally. A central warehouse orders in bulk from real suppliers and holds the stock; the shops basically buys on it as they need it.
Inter-store trade is how that draw works. The shop raises a purchase order against the warehouse, the warehouse gets a sales order for exactly that, and from then on the two are one agreement seen from both ends. When the warehouse ships, the shop already has the goods receipt waiting.
It covers the sideways case too. A customer wants a jacket your shop does not have, and another shop has one arriving Thursday — you can take it off their delivery without either of you leaving the system.
{% hint style="info" %}
#### Your central warehouse has to be a store
All of this is store to store, so the warehouse you supply the shops from must exist as a **store** in Flow Retail that holds its own stock. A warehouse sitting inside another store cannot sell to anyone.
{% endhint %}
***
## How it fits together
Two shops and a central warehouse, from the warehouse's order with the supplier to a customer collecting the goods.
***
## The three ways goods move
| | Who starts it | When the two orders link up |
| --------------------------------------------- | ----------------------- | ---------------------------------------------------------------- |
| **A shop orders from the warehouse** | The shop | When the shop sends the purchase order to the supplier |
| **The warehouse sends to a shop** | The warehouse | When the warehouse parks or confirms the sale, or is paid for it |
| **A shop takes from another shop's delivery** | The selling shop's till | The moment the goods are reserved for the customer |
Nothing links until a person says it is ready. Until then a purchase order is an ordinary draft the other store cannot see, and you can build it up and change it freely. That is deliberate: the other end should not be watching an order that grows, shrinks and changes price under its feet.
***
## What it costs the receiving store
Every line that crosses carries a price, and that price becomes the receiving store's **cost price** — the figure its margin is measured against when it finally sells the goods on. It comes from a price list, or from the purchase the goods are bought on plus a markup.
Prices are never copied between the two orders, and a change on one side never moves the other: a warehouse must not be able to shift a shop's stock value after the fact.
[What inter-store trade does to your figures](/docs/advanced-features/inter-store-trade/what-inter-store-trade-does-to-your-figures.md) works through the pricing rule, the VAT, and what Flow Retail does and does not settle between the two stores.
***
## What each side can change
Both stores keep editing their own order, and changes reach the other store straight away. Four rules bound it.
**A promise to a customer holds.** A line can be reduced down to what the receiving store has already reserved for its customers, but never below it. Whoever tries is told which store reserved the goods, on which purchase order, and how many. Ask them to release the reservation first.
**Once goods are on their way, the line is frozen.** From the moment the sending store sets the delivery to Delivered, that line is locked for them — goods are booked at the other end, and the sender cannot erase them. Credit the sale instead.
**Price never crosses.** Each side works out its own price when the line is created, and neither can move the other's. See [what it does to your figures](/docs/advanced-features/inter-store-trade/what-inter-store-trade-does-to-your-figures.md).
**A return flows back, until the goods are received.** When the sending store credits a sale and the return is settled, the receiving store's line shrinks or disappears, as long as the goods have not been received. Once they have, the line stands. After a return, neither store can change the line's quantity. See [Sell to another store](/docs/advanced-features/inter-store-trade/sell-to-another-store.md).
***
## What does not cross
The sale at the sending store is an ordinary sales order, so it can carry lines a purchase order cannot. Those stay where they are:
* Credits, returns, freight and services
* Products that may be sold but not bought
* Gift cards, configurable products and dynamic packages
A fixed package behaves differently: the receiving store gets the **components**, not the package line. The two orders then hold a different number of lines, and that is correct.
Every line that does cross needs a price above zero, components included. A line at zero is stock value the receiving store never agreed to.
{% hint style="warning" %}
Two other features sound like this one and are not:
* **Internal purchase orders** move your own goods between stores as a transfer — no purchase, no sale, no price.
* The **Central warehouse** extension marks one warehouse as central for delivery and stock lookups. It works independently of inter-store trade. Flow Assistant also uses it to list the central warehouse's shelf when you order for a customer.
{% endhint %}
***
## Where you do it
Setup happens in **Flow Admin**. The ordering, selling and receiving happens in **Flow Client** and **Flow Assistant**. For Assistant, see [Inter-store trade in Assistant](/docs/getting-started/software-clients/assistant/inter-store-trade.md).
***
## What's next?
* [Set up inter-store trade](/docs/advanced-features/inter-store-trade/set-up-inter-store-trade.md)
* [Buy from another store](/docs/advanced-features/inter-store-trade/buy-from-another-store.md)
* [Sell to another store](/docs/advanced-features/inter-store-trade/sell-to-another-store.md)
* [What inter-store trade does to your figures](/docs/advanced-features/inter-store-trade/what-inter-store-trade-does-to-your-figures.md)
* [Inter-store trade in Assistant](/docs/getting-started/software-clients/assistant/inter-store-trade.md)
*Last updated 13.10.2026*
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.flowretail.com/docs/advanced-features/inter-store-trade.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.