> For the complete documentation index, see [llms.txt](https://docs.fulfillmenttools.com/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fulfillmenttools.com/documentation/by-pillar/store-operations.md).
# Store Operations
Store Operations bridge the gap between order placement and the final delivery to the consumer. Once an order is allocated to a facility, Store Operations manages the physical handling of items, from locating and picking them from storage to packing them for shipment and finally handing them over for delivery or consumer collection.
## Operational journey
Once an order is routed to a facility, the local fulfillment process begins, managed through a series of jobs.
* [**Picking**](/documentation/by-pillar/store-operations/picking.md): A pick job is created, instructing a warehouse or store employee to gather the ordered items. The picker can confirm the quantity of each item. In cases of a short pick (when not all items are available), this information is critical for subsequent processes, such as splitting the order. Different picking methods include single order, multi-order, and batch picking, optimized by a configurable picking sequence.
* [**Packing**](/documentation/by-pillar/store-operations/packing.md): After all items are picked, a pack job is initiated. Here, the items are placed into one or more parcels. Shipping documents are generated, and if multiple parcels are used, the system tracks which items are in which package.
* [**Services**](/documentation/by-pillar/store-operations/services.md) (optional): Custom services allow for the creation of service jobs. A custom service could include trouser leg length alterations, embroidery on a shirt pocket, a custom strap for a watch, or bicycle assembly.
* [**Handover**](/documentation/by-pillar/store-operations/handover.md): The final step is the handover job. For ship-from-store orders, this involves handing the parcel to the designated carrier. The job is often completed automatically when the carrier scans the shipping label. For click-and-collect orders, it involves manually confirming the handover to the consumer.
* [**Returns**](/documentation/by-pillar/store-operations/returns.md) (optional): After an order is handed over, an `ItemReturnJob` is automatically created. This job contains all the `returnableLineItems` from the order. So, if a consumer wants to return their order, the complete lifecycle can be managed, from the consumer's announcement to receiving the item, assessing its condition, and triggering the refund process.
### Containers
Containers are a way to put items together during the operational process. These can be `VIRTUAL` or `PHYSICAL`. A physical container is one that exists and you can literally put items inside, like a box or a bag. A virtual container doesn't exist and is a way to group items in an order together in fulfillmenttools. So, even if you don't use containers in your operational process, we still need them in fulfillmenttools for store operations to work on our side.
Each part of the operational journey has a different container type. You can create containers that work for your operational flow and these are available for selection by the team members within our clients.
Operational module
Container
Virtual or physical
Picking
Load unit (optional)
Physical
Packing
Packing source container and Packing target container
Both
Services
Service container
Both
Handover
Handover container
Both
Returns
None
An [operative container type](/documentation/by-pillar/store-operations/packing/operative-container-types.md) can also be created so you create the container once and refer to it in the operational module container without duplicating information.
As an order makes it way through the operative process, it will flow through the different container types. So, the items within an order can be passed from container to container. For example, an order for click-and-collect consists of a T-shirt and a pair of sneakers. A picker selects the items and puts them into a load unit which is then placed in a location ready for a packer. A packer takes the items from the load unit (in packing, it's known as the packing source container), and puts the items into a packing target container and places it in a location ready for handover. The items are then put into a handover container and handed over to the consumer.
## Carrier management
[Carrier management](/documentation/by-pillar/store-operations/carrier-management.md) is key to automating the shipping process. You can integrate with shipping service providers to generate shipping labels, track parcels, and manage carrier-specific configurations like capacity, cut-off times, and non-delivery days. fulfillmenttools provides default carrier integrations, or you can create your own custom integration.
* Connects facilities with various shipping providers (carriers) to manage deliveries.
* Enables the creation of shipments and parcels, which triggers the generation of carrier-compliant labels and tracking numbers.
* Considers carrier-specific data, such as cut-off times, non-delivery days, and capacity limits during order routing and delivery promise calculations.
* Supports special services such as signature requirements or handling of bulky goods.
---
# 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.fulfillmenttools.com/documentation/by-pillar/store-operations.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.