> For the complete documentation index, see [llms.txt](https://docs.akinon.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.akinon.com/tutorials/oms/packaging-scenario-configuration.md). # Packaging Scenario Configuration This document explains what a packaging scenario needs in order to work, what happens to orders when the setup is incomplete, how to diagnose an order that could not be planned, how the package initial status behaves in Click & Collect (C\&C) and partial shipments, and when a transfer order is created for C\&C orders. The steps for creating a scenario are covered in the existing user documentation. This document adds the prerequisites that come before those steps and the failure situations that come after them. Intended audience: the teams that configure scenarios and handle support requests. No technical background required. *** ## 1. Key concepts | Concept | What it does | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Scenario** | Decides which rules are used to package an order. It is matched against order properties (sales channel, cargo company, payment type, customer segment, client type, date/time). | | **Rule** | The steps inside a scenario. A scenario can have several rules, tried in order. **Which warehouses or stores can fulfil the order is defined in the rule.** | | **Stock location** | The warehouse or store the order is fulfilled from. | | **Plan** | The system's decision of "this order ships from that location, in that package". Once a plan exists, a package is created. | | **Re-plan** | The action that cancels the current plan and re-evaluates the order. Used for out-of-stock, defective product, cancellation and similar cases. | | **Transfer order** | An instruction to move a product that is out of stock at the package's location from another location to that location. | | **Transfer scenario** | Decides which rules and which source locations are used for a transfer. It is configured **separately** from the packaging scenario. | *** ## 2. What a scenario must have in order to work ### 2.1 Mandatory fields on the scenario screen | Field | Required? | Description | | ---------------------------------------- | --------------------------- | ------------------------------------------------------------------------------------------------- | | **Scenario name** | Yes | Must be unique; a second scenario with the same name cannot be created. | | **Rule order** | **Yes — at least one rule** | A scenario without rules cannot be saved. Rules are tried in the given order. | | **Default stock location** | **Yes** | The system does not allow this field to be left empty, and only active locations can be selected. | | **Active** | Off by default | An inactive scenario is never considered for any order. Remember to activate it after setup. | | **Priority** | Assigned automatically | If several scenarios match, the one with the lower priority number is tried first. | | **Initial status for multiple packages** | No (optional) | See [section 6](#6-initial-status-for-cc-and-partial-shipments). | > ⚠️ **Common misunderstanding:** the "default stock location" is **not** the location the order is fulfilled from. It is used in one case only: when the order cannot be fulfilled from any location, the **"out of stock" package** that gets created is recorded against this location. The location that actually fulfils the order is decided inside the **rule**. ### 2.2 Location definition in the rule — the most critical step Every rule answers the question "which locations are candidates?". The available methods are: | Method | Meaning | | --------------------------------- | ------------------------------------------------------- | | Specific location list | Only the selected warehouses and stores are used | | Exclusion list | All locations except the selected ones | | Selection by distance | Locations within a given radius of the shipping address | | Selection by location type | Locations of the chosen type (warehouse, store, etc.) | | Selection by quota | Locations whose quota is not yet full | | Same area as the shipping address | Locations in the customer's area | > 🚨 **The most critical point:** the system saves a rule with no location method without any error. But when such a rule runs it **finds no location**: the plan comes out empty, the order cannot be planned, and no warning appears in the interface. This is the most common mistake made when setting up a scenario. > > **After saving a rule, always confirm that its location definition is filled in.** ### 2.3 What makes a location usable Being selected in the rule is not enough on its own. The location must also meet these three conditions: 1. The location must be **active**. 2. It must have a **stock source (stock integration) defined and active**. 3. It must be marked as a **packaging center**. If any of these is missing, the location never enters the stock query even when it is selected in the rule — meaning no package can come out of it. *** ## 3. What happens when an order arrives 1. The system scans **active** scenarios by priority and filters those matching the order's properties (channel, cargo company, payment type, segment, client type). 2. Further conditions are checked on the matching scenarios: order matching rules and the scenario's **operating schedule** (date range, or weekdays plus a time interval). 3. The **first** suitable scenario is selected. 4. The rules of that scenario are tried in order. If a rule fulfils the order completely the process stops; otherwise the next rule is tried. 5. If no rule produces a result, the order cannot be planned. Planning is evaluated at the moment the system attempts it, not at the moment the order arrives. Because waiting orders are retried every minute, an order can be planned by itself once a temporary obstacle is gone. *** ## 4. What happens when no location is configured ### 4.1 Two distinct failure situations **Situation A — No scenario matches at all** (scenario inactive, conditions do not hold, or outside the operating schedule) * The order is not planned. * **The order status does not change at all** and nothing is visible on screen. * The failure is only written to the system records (logs). **Situation B — A scenario matches but no location is found** (no location defined in the rule, location inactive, stock integration disabled, or no stock) * The order moves to the **"Failed Fulfillment"** status. * Where conditions allow, an **"out of stock" package** is created for the items and recorded against the scenario's **default stock location**. * Even so, no "could not be planned" warning appears in the interface. ### 4.2 What the user sees, per action | Action | Result | | ------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Automatic planning** (runs every minute for waiting orders) | No warning. The order stays unplanned and fails the same way on every attempt. | | **Automatic re-planning after an order cancellation** | No warning. | | **"Re-plan" from a package** | The action runs in the background, so the screen shows **success**; the failure only reaches the system records. | | **Automatic retry for out-of-stock packages** (every 3 hours) | No warning. | | **Re-planning with a manually selected location** | The action looks successful but **no new package is created.** | > **In short:** planning failures are not reported to the user. The only visible signal is the order dropping to **"Failed Fulfillment"**, and that happens only in Situation B. In Situation A the order simply waits, silently. > > For this reason, a "re-plan does not work" complaint should first be checked against the scenario and location setup; this behavior is usually not a product defect. ### 4.3 Under which conditions does "Re-plan" fail? The action produces no result in any of the situations below. What they all have in common is that no error message appears on screen: | Condition | How it looks on screen | | -------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | The order matches no active scenario's conditions | The order status does not change at all | | The scenario's operating schedule is not valid at that moment | The order status does not change; once inside the scheduled window the order is planned by itself | | The rule has no location definition | The order moves to "Failed Fulfillment" | | The locations in the rule are not usable (inactive, stock integration disabled, or not marked as a packaging center) | The order moves to "Failed Fulfillment" | | None of the candidate locations has enough stock | The items fall into an "out of stock" package | | Previously problematic location–product combinations were excluded from the candidate list, leaving no options | No new package is created | | No items are left to re-plan on the package (all cancelled or already shipped) | No new package is created | | The package is not in a status that allows re-planning | The action never starts | *** ## 5. How to diagnose an order that could not be planned ### 5.1 First, check the screen | What you see | What it means | | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Order status **"Failed Fulfillment"** | A scenario was found but no item could be fulfilled; there is a location or stock problem. | | Package status **"Out of stock"** | The items fell into an out-of-stock package. Its location is the scenario's default stock location. | | C\&C package in **"Waiting Transfer Operation"** | Transfer orders were opened for items that were out of stock at the store; the package is waiting for them to reach the store. This is expected behavior. | | C\&C order's items that were out of stock at the store fell into an out-of-stock package | No transfer could be made: check that the packaging rule allows transfers, the transfer scenario, and the source locations/stock (see [section 6.3](#63-transfer-orders-for-cc-orders)). | | **Order status unchanged and no package at all** | Most likely no scenario matched (Situation A). The setup needs to be reviewed. | ### 5.2 Setup check steps 1. **Is the scenario active?** 2. **Do the scenario's conditions match the order?** (channel, cargo company, payment type, segment, client type) 3. **Is an operating schedule defined?** If so, do the order's day and time fall inside it? 4. **Are rules attached to the scenario?** Is their order correct? 5. **Is the location definition in the rule filled in?** If a list method is used, is the list empty? 6. **Are the selected locations usable?** (active, stock integration on, marked as a packaging center) 7. **Is there actual stock at that location?** 8. **If the order is C\&C and the store is missing stock:** does the packaging rule allow transfers, is there an active transfer scenario matching the order, do the transfer scenario's schedule and matching rules fit the order, and are the source locations in the transfer rule usable and stocked? If one of these steps reveals a gap, that is almost certainly the cause. ### 5.3 What to ask the technical team for If the screen gives no answer, give the technical team the order number and ask them to review the system records. Those records answer: * Was planning ever started for the order? * Could a suitable scenario be found? * Did the rule return any location at all? * Why did the re-plan attempt produce no result? The main messages the system can produce, and what they mean: | Message | Meaning | | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | *There is no packing rules available for execution* | The order matched no active scenario's conditions | | *There are no validated packing scenarios available for execution* | A scenario matched but failed the order matching rules or the operating schedule check | | *There are no stock locations in given rule for creating stock map* | The rule has no usable location | | *Order Execution Plan does not created for Order* | The plan came out empty; the order was set to "Failed Fulfillment" | | *There is no order item to replan* | There are no items left to re-plan | | *There are no validated transfer scenarios available for execution!* | An order needing a transfer matched a transfer scenario, but it failed the order matching rules or the operating schedule check; planning stopped entirely | *** ## 6. Initial status for C\&C and partial shipments ### 6.1 When does the "initial status for multiple packages" setting apply? When this field is filled in, the packages created by the scenario open in the status you selected instead of the usual **"Waiting"** status. However, the setting is **not applied to every order**; it only takes effect in these two cases: 1. The order is fulfilled from **more than one location** (that is, more than one package is created), **or** 2. Only **part** of the order can be planned (some items stay out of the plan due to cancellation or lack of stock — a partial shipment). If the order fits into a single package and is fulfilled completely, the setting is **not applied** and the package opens as "Waiting". This is not a defect but the expected behavior. > **Footnote — this setting was designed for marketplace orders.** On the marketplace side an order can be shipped in several parts, so packages that come out split need to start in a different status than the normal flow. Orders from your own channels (web, store, etc.) that ship as a single package never show the effect of this setting, which is why filling the field in on a non-marketplace scenario is usually unnecessary. > **Additional note:** in re-plans where the location is selected manually, this setting is **never applied**; those packages always open as "Waiting". ### 6.2 Prerequisites for Click & Collect planning For C\&C planning to take effect: * the order must carry a **store (the pickup store)**, **and** * the Click & Collect feature must be **enabled** in the system settings. Behaviors specific to C\&C: | Behavior | Consequence | | --------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | The location comes from the store on the order, **not from the rule** | The rule's location selection methods do not determine the packaging location in C\&C | | If the store on the order is not usable | No item can be planned from the store. If no transfer is possible, **an empty plan is produced silently** and the order drops to "Failed Fulfillment". The store must be active, have an active stock integration, and be marked as a packaging center or a delivery location — for C\&C the delivery location flag is also sufficient. | | If not all items on the order match the rule | No plan is produced ("all items in one package or none") | | An item with no stock at the store | The system first tries to **transfer** it to the store from another location (see [section 6.3](#63-transfer-orders-for-cc-orders)). If no transfer is possible, the item does not enter the plan and falls into an out-of-stock package. | > If the "predefined package location" feature is enabled in the system, the packaging location is read directly from the location information on the order item and the C\&C logic does not come into play. ### 6.3 Transfer orders for C\&C orders In a C\&C order the package is always created at the store where the customer will pick it up. For items that are out of stock at the store, the system tries to create a **transfer order** that brings the product to the store from another location. For this reason, every setup that uses C\&C must check whether a transfer can occur and whether a suitable transfer scenario exists. #### When is a transfer attempted? When **all** of the following hold: 1. The store cannot fulfil every item on the order from its own stock (at least one item is out of stock at the store, or the store is not usable). 2. **Allow transfer orders** is enabled on the packaging rule being run. 3. An **active transfer scenario** suitable for the order exists. If the store can fulfil every item, transfer scenarios are not consulted at all. #### How is a suitable transfer scenario chosen? Transfer scenarios are independent of packaging scenarios and are matched the same way: * **Active** transfer scenarios are scanned in priority order. * Those matching the order's channel, cargo company, payment type, customer segment and client type are kept. * The order matching rules and the **operating schedule** are checked for the rest; the first suitable scenario is used. * The scenario's rules are tried in order; the system stops once all missing items are covered by transfers. #### Which locations can be a source in the transfer rule? * It must be selected in the transfer rule's location definition (a rule whose location definition is empty **finds no location**, just like a packaging rule). * It must be active, have an active stock integration and be marked as a **delivery location**. * It must have enough stock of the product. * The order's store is never used as a source. > **The destination is always the store on the order.** Destination preconditions on the transfer rule (such as "transfer only to selected package locations") do not change where a C\&C transfer goes. #### Outcomes | Situation | Result | | ----------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Transfer succeeds | The package is created at the store and moves to **"Waiting Transfer Operation"**. Items that will arrive by transfer wait in "Selected for Transfer". Stock is reserved for the transfer at the source location. Once the transfers reach the store, the package continues in the normal flow. | | The packaging rule does not allow transfers | No transfer is attempted. If partial packing is enabled, the missing items fall into an out-of-stock package; if not, this rule produces no result and the next rule is tried. | | No active transfer scenario matches the order | No transfer happens, **silently**; the result is the same as the row above. | | A transfer scenario matches on channel, cargo company, etc., but its order matching rule or operating schedule does not | **Planning stops entirely**; the order status does not change and no package is created. The error is written only to the system records (*There are no validated transfer scenarios available for execution!*). | | The transfer rule has no usable source location or no stock | The transfer plan stays empty; the result is the same as the "does not allow transfers" row. | | Transfers can cover only some of the missing items | If partial packing is enabled, the ones found are transferred and the rest fall into an out-of-stock package. If not, this rule's plan is discarded entirely. | | No rule (packaging + transfer) can fulfil even a single item | The order drops to "Failed Fulfillment". | > 🚨 **Watch out:** If the transfer scenario is restricted by an operating schedule, C\&C orders that need a transfer and arrive outside that schedule are **not planned at all** and wait silently. Once the schedule window opens, the order is planned on the next automatic attempt. *** ## 7. Checklist for setting up a new scenario * [ ] The scenario is marked **active**. * [ ] A **default stock location** is selected and that location is active. * [ ] At least one **rule** is attached, in the correct order. * [ ] Every rule has a **filled-in location definition** that really returns locations. * [ ] The selected locations are active, have an active stock integration, and are marked as a **packaging center**. * [ ] Channel / cargo company / payment type / segment / client type conditions match the targeted orders. * [ ] If an operating schedule is defined, it covers the days and hours when orders arrive. * [ ] "Initial status for multiple packages" is filled in only for a marketplace multi-package or partial-shipment flow, with the awareness that it has no effect on single-package orders. * [ ] For C\&C, the feature is enabled and the store location is usable. * [ ] For C\&C, if the store may run short of stock: the packaging rule allows transfers, an **active transfer scenario** matches the orders, its schedule and matching rules cover them, and the transfer rule has source locations defined and marked as **delivery locations**. * [ ] If transfers are not wanted, transfers are disabled on the packaging rule and the partial packing setting was chosen deliberately (if enabled, missing items fall into an out-of-stock package; if not, the rule produces no result). * [ ] The setup was verified with a **test 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.akinon.com/tutorials/oms/packaging-scenario-configuration.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.