> 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" %}
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/prices.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, to promise consumers.
* They act as key routing factors used to determine the best sourcing path for a (potential) order.
## Total cost calculation
{% hint style="info" %}
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 you to define transport costs, sales prices, and discounts for use in the routing decision. Depending on the configuration, these cost rates are summed to determine 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 they determine transport costs. The detailed explanation of the algorithms and calculation steps can be found in the [Transport cost calculation article](/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
You can include an item's sales price in the total cost calculation. These prices can vary by facility and are therefore maintained in the supplying facility's listing entity. 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. Sales prices can also be defined based on tags applied to an order. This lets suppliers differentiate prices by sales channel, customer group, or other contextual information represented by an order tag. When an order contains a specific tag, fulfillmenttools 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, fulfillmenttools calculates the item's sales price if the corresponding rating is activated. The sales price is taken from the listing in the supplying facility. You can set multiple sales prices and assign each a priority and a context. Based on this information, fulfillmenttools can determine and apply different sales prices 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" to the different sales prices and their configured contexts based on priority. This also applies if the receiving facility is an intermediate hub. For example, when goods move from Supplier 4711 to the Central Warehouse and then to the 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 if 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. Discount rates can be set as a percentage or an absolute value. They 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 corresponding discount is calculated using 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 match, the discount applies to the item's sales price.
**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 to within the listing: [Categories](/documentation/by-pillar/global-inventory-hub/categories/category-endpoints.md)
* For bundling facilities: [Facility groups](https://fulfillmenttools.github.io/fulfillmenttools-api-reference-ui/#post-/api/facilitygroups)
### Multi-currency
In a cross-border fulfillment network, you must 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 to use for price evaluation. The ordering party can either be the consumer or an ordering facility.
If the order includes a currency in the payment information, that currency defines the sales price for the supplying facility's listing. If this information isn't explicitly provided, fulfillmenttools determines the appropriate currency 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 checks the receiving facility's country and uses that country's currency.
For click-and-collect orders, the same logic is used. If the click-and-collect order does not specify a currency, the system falls back to the pickup facility's local currency.
### 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 are either:**
* Package-specific transportation costs on `packagingUnitByContext`
* 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 by the consumer country
* Discounts are optional. Their absence won't 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 placed an order that was split into two parcels. The first is shipped from the store in New York. The store in Los Angeles is missing some items, so it must first recieve them from its 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 because it lacked cost information for the transfer from 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 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/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 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.
