> 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/advanced-order-routing/complex-routing-with-combinatorics/calculations-within-routing.md). # Calculations within routing {% hint style="info" %} If you would like to use these functionalities, [contact our Support team](https://ocfulfillment.atlassian.net/servicedesk/customer/portal/1) for more information and activation support. {% endhint %} In the optimization phase of the routing process, calculations are performed for each sourcing option based on the configured rules. These rules include: * A total cost calculation for each sourcing path, considering the configured components such as [purchase prices](/documentation/getting-started/facilities/prices.md#purchase-price) (including [discounts](/documentation/getting-started/facilities/facility-discounts.md)) and shipping costs. * The calculation of the **expected delivery date**. The results of these calculations can serve two purposes: * They can be provided to external systems, such as a web shop, for promising to consumers. * They act as key routing factors used to determine the best sourcing path for a (potential) order. ## Total cost calculation {% hint style="info" %} If you would like to use these functionalities, [contact our Support team](https://ocfulfillment.atlassian.net/servicedesk/customer/portal/1) for more information and activation support. {% endhint %} fulfillmenttools allows defining transport costs as well as sales prices and discounts for usage in the routing decision. Depending on the configuration these cost rates are added up and used in the total cost rating. ### Transport costs Transport costs represent the expenses incurred when goods are shipped between facilities or from a facility to the end consumer. These costs typically depend on the shipping service provider, the parcel or packaging type used, the destination country, and — depending on the chosen logic — additional factors such as weight or volume. There are **two different levels of granularity** for calculating transport costs within fulfillmenttools: * A **standard logic**, suitable for homogeneous carrier portfolios and simple pricing structures * An **advanced logic**, designed for heterogeneous carrier portfolios, multiple shipping methods, and scenarios where optimized packing and price calculation significantly influence fulfillment costs These two logics differ fundamentally in how transport costs are determined, the detailed explanation of the algorithms and calculation steps can be found here for a full breakdown of both approaches: [Transport cost calculation logic](/documentation/by-pillar/advanced-order-routing/complex-routing-with-combinatorics/calculations-within-routing/transport-cost-calculation-logic.md) **The data can be configured in the platform via REST APIs:** * For the dimensions of the item: [Listings attributes](https://fulfillmenttools.github.io/fulfillmenttools-api-reference-ui/#get-/api/facilities/-facilityId-/listings) * For the dimensions and pricing of the packaging unit [Facility connection](https://fulfillmenttools.github.io/fulfillmenttools-api-reference-ui/#get-/api/facilities/-facilityId-/connections) and [Packaging unit](https://fulfillmenttools.github.io/fulfillmenttools-api-reference-ui/#get-/api/packagingunits) * For the fallback costs: [Facility connection](https://fulfillmenttools.github.io/fulfillmenttools-api-reference-ui/#get-/api/facilities/-facilityId-/connections) {% hint style="info" %} See the [facility connection article](/documentation/by-pillar/advanced-order-routing/complex-routing-with-combinatorics/network-model/facility-connection.md) for more information. {% endhint %} ### Sales prices and discounts It's possible to include an item's sales price in the total cost calculation. These prices can vary from facility to facility and are therefore maintained in the listing entity of the supplying facility. Furthermore, the sales price can depend on who is requesting those items. For this reason, multiple sales prices can be maintained in the entity, each with its own priority and context. In addition, sales prices can also be defined based on tags applied to an order. This enables suppliers to differentiate prices depending on the sales channel, customer group, or any other contextual information represented by an order tag. When an order contains a specific tag, the platform can automatically select the corresponding sales price entry, enabling flexible, context‑aware pricing without maintaining separate listings. #### **Sales price calculation** **Determination of the sales price** When an order is placed, the sales price of an item is calculated if the corresponding rating is activated. The sales price is taken from the listing in the supplying facility. It is possible to set multiple sales prices and to assign them both a priority and a context. Based on this information, different sales prices can be determined and applied depending on the order's origin. If the sales price is defined based on the requesting facility or facility group, the `facilityRef` of the direct receiving facility (the immediate recipient of the goods) serves as the starting point for the determination. This receiving facility (and optionally its facility group) is "matched" with the different sales prices and their configured contexts according to their priority. This also applies if the receiving facility is an intermediate hub. For example, in the case of goods moving from Supplier 4711 to the Central Warehouse to the end consumer, the Central Warehouse determines the sales price used in the calculation. By storing a sales price without context, this price check can be bypassed, or a fallback value can be stored in case the previous context determination doesn't yield a match. **Determination of the discount** Additionally, users can define a discount that should be applied to the sales price. The discount rates can be set up either as a percentage or an absolute value and can be determined differently depending on the purchaser/receiving facility and the [category](/documentation/by-pillar/global-inventory-hub/categories.md) of the item. The calculation of the corresponding discount follows a logic similar to the sales prices. The contexts set in the discount (for example, facility groups or categories) are matched with the corresponding context of the listing. If all contexts are matching, the discount will be applied to the sales price of the item. **The data can be configured in fulfillmenttools via REST APIs:** * For the `salesPrice` and its context: [Listings](https://fulfillmenttools.github.io/fulfillmenttools-api-reference-ui/#get-/api/facilities/-facilityId-/listings) (for different currencies different attributes must be set) * For the `discounts` and its contexts: [Discounts](https://fulfillmenttools.github.io/fulfillmenttools-api-reference-ui/#get-/api/facilities/-facilityRef-/discounts) * For the mapping of the purchaser `facilityRef`: [Order](https://fulfillmenttools.github.io/fulfillmenttools-api-reference-ui/#post-/api/orders) * For creating categories of an item which can be referred within the listing: [Categories](/documentation/by-pillar/global-inventory-hub/categories/category-endpoints.md) * For bundling facilities: [FacilityGroups](https://fulfillmenttools.github.io/fulfillmenttools-api-reference-ui/#post-/api/facilitygroups) ### Multi-currency In a cross-border fulfillment network, it is essential to account for the different currencies used across countries. Entities that store routing-relevant prices and costs can thus define various currencies. {% hint style="warning" %} These values are always interpreted as the smallest unit of the respective local currency (for example, Euro cents in the Eurozone). {% endhint %} The ordering party defines which currency should be used for price evaluation. The ordering party can either be the end consumer or an ordering facility. If the order includes a currency via the payment information, this currency defines the sales price for the listing of the supplying facility.\ If this information is not explicitly provided, the appropriate currency is determined based on the country code of the consumer's postal address. The same logic applies when a facility places an order. In this case, it is checked which country the receiving facility is based in and this countries currency is used then. For Click & Collect orders, the same logic is used. If no explicit currency is provided in the Click & Collect order, the system will fall back to using the local currency of the pickup facility. ### Minimum data requirements for cost calculation Specific parameters must be available (depending on the rating configuration) to ensure accurate total cost calculation for a supply route. {% hint style="warning" %} If even one of these values is missing, the cost calculation will fail, and the entire supply route will receive the maximum penalty for the cost rating. {% endhint %} **Transportation costs:** * Either package-specific transportation costs on `packagingUnitByContext` * Or fallback `transportCosts` **Sales prices:** * A `salesPrice` at the listing level of the supplying facility must be provided. If contexts are defined, at least one context must match to ensure a valid sales price. * The corresponding sales price must be stored in an appropriate currency. The applicable currency is determined by the `paymentInfo` in the request, or alternatively by the consumer country * Discounts are optional. Their absence will not cause the calculation to fail. If both components are active within the total cost rating, all the above conditions must be met. Otherwise, the entire supply route will also receive the maximum penalty. **Example 1** In the example below, a consumer has made an order which has been split into two parcels. The first is shipped from the store in New York. The store in Los Angeles is missing some of the items, so they must first be shipped to the store from their supplier.
All cost information is gathered from the detailed packaging unit costs. The total transport costs for the sourcing options amount to **€15.20**. **Example 2**
In the example above, part of the transfer was calculated using detailed package-specific costs, while another part was based on fallback costs. The total transport costs for the sourcing options amount to **€21.40**. **Example 3**
In the example above, the cost calculation failed, due to a missing cost information for the transfer Store Los Angeles to the Consumer. --- # 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://docs.fulfillmenttools.com/documentation/by-pillar/advanced-order-routing/complex-routing-with-combinatorics/calculations-within-routing.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.