> 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/fulfillment/how-fulfillment-works.md). # How fulfillment works Fulfillment is everything that happens between a confirmed customer order and the moment the customer can use what they ordered. A service is an agreement rather than a product: something you provide for a term, at a price, on agreed conditions. What it takes to deliver one depends entirely on what the service contains. A notebook has to be bought, prepared and sent. A software licence has to be assigned. Some services need nothing beyond a record that they are now running. Fulfillment is that work, and the record of it. Read this page before the others in this section. It explains the pieces the rest of the documentation assumes. ## What the customer ends up with Two things exist once an order has been fulfilled, and keeping them apart saves a lot of confusion later. The **service instance** is the customer's copy of the service. It runs for the agreed term, it shows up in their inventory, and it is what gets billed. The **service components** are the individual items that make it up. One entry each, carrying whatever attributes you defined on the product, such as a serial number, an IMEI or a PIN. The difference matters in daily work. If a device breaks and you exchange it, you replace a component while the instance keeps running, so the term and the price stay untouched. If the customer gives the service back, the instance ends. ## Why an order becomes positions A customer order usually contains more than one item, and the items rarely travel together. One may be in stock while the other has to be ordered. Two identical notebooks may go to two different offices. A licence needs no handling at all while the hardware next to it does. So every item becomes its own **position**, and each position moves at its own speed. An order can have four positions, three still waiting on purchasing while the fourth is already in transit. Everything in this section happens at position level. You work on positions, not on orders. ## Where the work comes from You do not decide what has to happen to a position. The service mapping already did. The mapping holds the bill of materials for the service, meaning everything that has to be there for one delivery. Each kind of entry produces a different kind of work. | Entry in the bill of materials | What fulfillment has to do | | --------------------------------------------- | ---------------------------------------------------------------- | | An article flagged as a **stock item** | Procure it and move it through the warehouse | | An article not flagged as a stock item | Nothing to procure. It is recorded as a component of the service | | A product of the category **production step** | A task appears on the position for someone to work through | Production steps are how you put your own work into the process. Say you offer a notebook that has to be set up before it leaves the building. In the mapping you add the notebook itself, plus two production steps called Set up device and Install software. When a customer orders it, the position arrives with those two steps attached, and whoever handles it works through them in order. Nothing ships until the last step is closed. Steps also cover work that has nothing to do with hardware. A return, for example, typically carries Send label and Process return. If a service has no released mapping, fulfillment does not know what the service consists of. The position waits until you complete the mapping and release it. This is worth internalising early: almost everything fulfillment does was decided in the portfolio. ## The four routes a position can take **The article is already in stock.** Nothing has to be bought. The position goes straight to [Picking](/documentation/fulfillment/picking.md), and from there to [Shipping](/documentation/fulfillment/shipping.md). **The article is not in stock and you fulfil in house.** The position waits for purchasing. It appears as demand in [Order proposals](/documentation/purchasing/order-proposals.md), you place a purchase order with your distributor, you book the goods in through [Goods receipt](/documentation/warehouse/goods-receipt.md), then pick and ship. **The service is set to dropshipping.** Your distributor ships directly to the customer, and nothing passes through your warehouse. The demand appears in Order proposals under the Dropshipping tab and you place the order there. From the moment that purchase order exists, you steer the position from Purchasing rather than from Fulfillment, so the status field on the position itself is no longer available. **There is nothing physical.** Software, licences and pure services have nothing to procure and nothing to ship. You record what you did and complete the position. Production steps can appear on any of these routes. Where they exist, they set the pace: you work through them in order, and the last one ends the production stage. Submitting the shipment is what closes the position, unless there is nothing to ship. The board below shows the whole flow with every decision point. {% embed url="" %} ## The screens in this section They are not separate departments handing work to one another. They are the same positions, listed in different places depending on what you want to see. | Screen | What you find there | | ------------------------------------------------------------------------ | -------------------------------------------------------------------------- | | [Open positions](/documentation/fulfillment/open-positions.md) | Orders that have not been completed yet. Your main work list | | [Picking](/documentation/fulfillment/picking.md) | Positions whose goods are in the warehouse and have to be taken out | | [Production](/documentation/fulfillment/production.md) | Positions with production steps waiting to be worked through | | [Shipping](/documentation/fulfillment/shipping.md) | Positions ready to send, plus preordered items the customer has called off | | [Changes](/documentation/fulfillment/changes.md) | Exchanges that are being processed | | [Pending activations](/documentation/fulfillment/pending-activations.md) | Positions whose activation still has to be set | | [Completed positions](/documentation/fulfillment/completed-positions.md) | Everything that has been delivered and closed | | Cancellations | Positions cancelled by you or by the customer | Some of these lists group positions by **what kind of job they are**, and others by **what has to happen to them next**. That is why the same position can appear in two of them at once. An exchange that is waiting to be picked shows up in Changes, because an exchange is what it is, and in Picking, because picking is what it needs next. Both entries open the same position, and work done in one is immediately visible in the other. Open positions and Changes are the two lists you start from. The stage-based lists in between exist so that warehouse and workshop staff only see the jobs that concern them, rather than the whole workload. ## Fulfillment does not stop at delivery A service instance has a life after it starts. The customer may report a problem and request an exchange, hand the service back, or cancel it. Each of those creates a **new position** of its own type, which you handle in this section like any other. A return appears in Open positions alongside ordinary orders. An exchange appears in Changes. They behave slightly differently from a first delivery, and the pages for those cases explain how. ## Statuses at a glance Every position carries a process status that tells you what has to happen next. | Status | What it tells you | | ----------------------------- | ------------------------------------------------------------------------ | | Waiting for mapping approval | The service has no released mapping, so the bill of materials is missing | | Awaiting purchase | The articles are not in stock and a purchase order is needed | | Ordered (confirmed) | A purchase order exists and the goods are on their way to you | | Ready for picking | The goods are in the warehouse and can be taken out | | Ready for production | Production steps are waiting to be worked through | | In progress | Work has started | | Ready for delivery | Prepared and ready to ship | | Delivery requested (outgoing) | The customer has called off a preordered item | | In delivery (outgoing) | On its way to the customer | Alongside this, the overview panel on the right of a position shows the status of the customer order as a whole, and the service instance and its components carry statuses of their own. The same word can appear on different objects and mean different things, so check what a status belongs to before you act on it. ## When a position will not move Look in the portfolio first. These are the settings that decide what fulfillment can and cannot do. | Configured on the service or product | Effect in fulfillment | | ------------------------------------------- | ------------------------------------------------------ | | Mapping released or not | Whether the position knows what to deliver | | Stock item flag on the article | Whether procurement and the warehouse are involved | | Products of category production step | Whether production steps appear | | Provisioning type, in house or dropshipping | Which route the position takes | | Preorders allowed on the offer | Whether items can be called off later | | Product attributes marked mandatory | Whether a serial number is requested during processing | A position stuck at Waiting for mapping approval, or one that never reaches purchasing, is almost always a configuration question rather than a fulfillment problem. --- # 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/fulfillment/how-fulfillment-works.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.