> 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/day-to-day-operations/purchase-and-receivement/purchase-requests.md).

# Purchase requests

How selling something you do not have turns into a purchase order, and where to find what is waiting to be ordered.

When you sell something you do not have in stock, the order line can be reserved against a purchase order that **does not exist yet**. That creates a **purchase request** — a standing note that this product needs buying, for this customer, on this order.

Purchasing then works from that list rather than from memory.

## Where a request comes from

A request is created by the sale, not by purchasing. Setting an order line's reservation to **request purchase order** is what raises it — see [Order lines](/docs/day-to-day-operations/selling/order-lines.md).

The line reserves immediately, even though nothing is on order yet. That is the point: the customer is promised the goods, and the promise is recorded against something purchasing can act on.

## Two ways to look at the list

| View           | Shows                                                        | Use it when                                                           |
| -------------- | ------------------------------------------------------------ | --------------------------------------------------------------------- |
| **By product** | Every requested product, aggregated                          | You are placing orders with suppliers and want quantities per product |
| **By order**   | The same requests, grouped by the sales order they came from | You are chasing one customer's order, or prioritising by promise date |

Both views filter on organisation, store, supplier and order state.

The by-product view is the one that saves money — five customers each waiting for the same item become one line with a quantity of five, and one order to the supplier.

## Turning requests into a purchase order

Requests are a worklist, not an order. Nothing reaches the supplier until a purchase order is created and sent, at which point it follows the normal lifecycle — see [Purchase order statuses](/docs/day-to-day-operations/purchase-and-receivement/purchase-order-statuses.md).

As the goods move, the reservation on the sales line follows:

| Stage                           | Reservation on the sales line          |
| ------------------------------- | -------------------------------------- |
| Requested, nothing ordered      | `REQUEST_PURCHASEORDER`                |
| Purchase order placed           | `PURCHASEORDER`                        |
| Supplier confirmed the shipment | `PURCHASEORDER_CONFIRMED`              |
| Goods received                  | Stock exists, and the line draws on it |

## Purchase requests versus Max/Min

Two different reasons to buy, and they answer to different things.

|                    | Purchase request | Max/Min                               |
| ------------------ | ---------------- | ------------------------------------- |
| Triggered by       | A customer order | Stock falling to or below the minimum |
| Quantity           | What was sold    | Enough to reach the maximum           |
| Tied to a customer | Yes              | No                                    |

A request is demand you have already committed to. [Max/Min](/docs/day-to-day-operations/purchase-and-receivement/max-min.md) is replenishment. Most stores need both.

Note that Max/Min can be told to exclude reserved stock from its calculation. With that on, stock already promised to a customer is not counted as available — which keeps the two mechanisms from quietly cancelling each other out.

## What this means for you

* **Check the request list before placing supplier orders.** Ordering from Max/Min alone misses everything customers are already waiting for.
* **A reserved line is not stock.** A request reserves against goods nobody has ordered yet. Only receiving makes it real — see [Receiving goods](/docs/day-to-day-operations/purchase-and-receivement/receiving-goods.md).

## Limitations

* A request is raised per order line. Two lines for the same product on the same order are two requests, aggregated only in the by-product view.

***

*Last updated 19.09.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/day-to-day-operations/purchase-and-receivement/purchase-requests.md?ask=<question>&goal=<user_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.