> For the complete documentation index, see [llms.txt](https://hub.equipme.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.equipme.io/documentation/purchasing/order-proposals.md). # Order proposals Order proposals is your buying list, and it fills itself. Whenever something is needed and not available, equipme works out what has to be bought and puts it here. You never create a proposal. If something you expect is missing, the cause is upstream, not on this page. ## Where demand comes from Two sources, and they are easy to confuse because they arrive in the same row. **A customer order** that cannot be served from stock. Three things have to be true for it to reach this page: the service has a **released mapping**, that mapping contains **articles**, and the order has been **confirmed**. Miss any one and the position sits at Awaiting purchase with nothing to buy against it. **Your own minimum inventory.** Where a product has a minimum stock level, equipme keeps proposing whatever it takes to get back to it, with no customer behind it at all. So the quantity in the list is not simply the number of customers waiting. **Click the row** and a window opens listing exactly what the demand is made of: each customer order with its number, and a separate line for minimum inventory. The two are not added together. The larger one wins, because restocking to your minimum already covers the customer who is waiting. The quantity can be edited in that window. Use it when you disagree with the proposal, for example when you want the one device the customer needs and not the stock buffer as well. ## Two tabs, two different jobs **Stock purchase** is what you buy for your own warehouse: you receive it, book it in, pick it and ship it. **Dropshipping** is what your distributor sends straight to the customer. Nothing passes through your hands. Which tab demand lands in follows the service configuration, not a decision you make here. On a dropshipping proposal, look at the **delivery address** before ordering. It comes from the location in the customer's order and it is where your distributor will actually ship. Getting it wrong means the device arrives at the wrong office. ## Turning demand into an order Select what you want to buy and click Order. The reason demand collects here rather than triggering an order per item is that you can **combine positions into one purchase order**, as long as they go to the same supplier. Five customers ordering the same notebook this week is one order to your distributor, not five. Only the supplier is mandatory, prefilled from the product. Everything else can be added later as information comes back, so nothing stops you placing the order today. Still, three things are worth entering while you are there: the distributor's order number, so the delivery can be matched to it; the expected delivery date, which your warehouse sees in [Goods receipt](/documentation/warehouse/goods-receipt.md); and the real unit price, if it differs from the default in the product master data. {% embed url="" %} ## What changes afterwards The demand disappears from this list and a purchase order exists under [Orders](/documentation/purchasing/orders.md). The position itself does **not** move yet. Its Purchase demand block now names the purchase order, but the status stays where it was until the goods are booked in through [Goods receipt](/documentation/warehouse/goods-receipt.md). From this point the position is steered from Purchasing. On a dropshipping position the status field is disabled entirely, and whatever you record on the purchase order is what moves it. ## If something looks wrong | Symptom | Usual cause | | ----------------------------------------------------------- | ----------------------------------------------------------------------------- | | A position waits at Awaiting purchase but no demand appears | The mapping is not released, or contains no articles | | The quantity is higher than the number of customers waiting | A minimum inventory level is topping it up. Open the row to see the breakdown | | Demand appears with no customer behind it at all | Same reason. It is a restock, not an order | | Demand appears under the wrong tab | The provisioning type on the service is set the other way | | The delivery address is not what you expect | It comes from the location in the customer's order | | The price is wrong | The default on the product is out of date. Overwrite it on the order | --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://hub.equipme.io/documentation/purchasing/order-proposals.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.