> 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/products/adding-products/package-products.md).

# Package products

Sell several products as one item, and understand how the package price is split across what is inside it.

A **package** is one product on the order that is made up of several others — a bundle, a kit, a starter set. The customer sees one line and one price; Flow Retail keeps the components underneath so stock and cost stay right.

## Two kinds of package

| Product type      | What it means                                                                 |
| ----------------- | ----------------------------------------------------------------------------- |
| `PACKAGE_FIXED`   | The contents are fixed. Every one of these packages contains the same things. |
| `PACKAGE_DYNAMIC` | The contents are chosen when it is sold, from the slots you define.           |

Use fixed for a bundle that never varies. Use dynamic where the customer picks — a three-for-two on any shirt, a hamper where they choose the contents.

## How the package price is split

The package carries the price. The components underneath still need a value each, for margin and reporting, so Flow Retail distributes the package price across them.

**Components are weighted by their own price.** A component worth twice as much as another takes twice the share of the package price.

| Component | Own price × qty | Share of a 1 000.00 package |
| --------- | --------------- | --------------------------- |
| A         | 600.00          | 500.00                      |
| B         | 300.00          | 250.00                      |
| C         | 300.00          | 250.00                      |

Two rules handle the edges:

* **Components priced at zero** share whatever is left after the priced ones have taken their cut, split by quantity.
* **The rounding remainder goes to the first component line.** Percentages rarely divide cleanly, and the leftover øre has to land somewhere.

That means a component's line value in a package is *derived*, not the price you set on the product. Do not read it as the product's own price.

## How the package's cost is worked out

The other direction. The package's cost price is the **sum of its components' costs**:

`package cost = total of (component cost × component quantity) ÷ package quantity`

So a package is never cheaper or dearer to you than the sum of what went into it. Margin on a package is the package price against that total — which is why a bundle discount shows up as reduced margin rather than reduced stock value. See [How cost price is calculated](/docs/day-to-day-operations/prices/how-cost-price-is-calculated.md).

## What this means for you

* **Price the components sensibly even inside a fixed package.** Their relative prices are what decide how the package price is split, and that split drives per-product margin reporting.
* **A zero-priced component is not free.** It picks up a share of the remainder. If you want a genuine giveaway inside a package, expect it to absorb value.
* **Check the first component line** when a package total looks a few øre off. That is where rounding is deliberately parked.

## Limitations

* Component line values are derived from the package price. Editing a component price on the order does not change what the customer pays for the package.
* Stock moves per component, not for the package as a unit.

***

*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/products/adding-products/package-products.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.