Total cost calculation

If you would like to use these functionalities, please contact our Professional Services team for more information and activation support.

The fulfillment platform allows defining transport costs as well as sales prices & 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

Introduction

The transport costs represent the costs incurred when goods are shipped between two facilities or between a facility and the consumer. These costs usually depend on the different cost rates of the shipping service providers, the different parcel types used for shipping, and the destination countries. Another factor can be shipped weight or the shipped volume.

Transport cost calculation

When multiple shipments are made between facilities and/or consumers, the associated costs are aggregated. Additionally, if several packages are dispatched, these costs are accumulated.

Thus, a case calculation is performed:

  • Check whether the biggest item would generally fit into the package with the highest priority (which is most of the time the smallest and cheapest to ship), looking on the dimensions of the item and the package.

  • When it does not fit the next package is tried (defined by the priority). If it fits: Check for the next item to fit in this package.

  • Do this for every item. If a package is full: check for a second package starting again with the package with the lowest priority.

  • A parcel is full when the sum of the item volumes exceeds the inner parcel volume. However, an empty space is deducted to ensure that the items really fit. Note: Geometries are not considered and no "Tetris" is played. Therefore, it is important to leave some empty space.

  • A parcel is also full if the max-item-amount is reached. This feature enables users to make sure that only one item is put into single packages.

Sometimes the package and its transport cost is not enough to handle transport costs complexity. Therefore, it is also possible to add another cost-factor to the packaging price. This is done by the coefficient. If this coefficient and its type (volume or weight) is set additionally to the package base price, a price “€ per KG” or “€ per volume” is added. Decimal places are rounded up – a package with 2.8 kg would be calculated as 3x X€.

After having determined the packages and their prices which are being used for the transport, the costs above all the connections between the facilities (and the customer) are added up.

If package cannot be calculated, e.g. due to missing data, or no packages are set up at all, “fallback”-costs are used.

The data can be configured in the platform via REST APIs:

More information on configuring dimensions can be found in the Developer Docs.

More information on facility connections can be found here.

Sales prices & discounts

Introduction

It is possible to include the sales prices of an item into the total cost calculation. Those prices can vary from facility to facility and therefore, are maintained in the listing entity of the supplying facility. Furthermore the sales price can depend on who is requesting those items. Therefore, multiple sales prices can be maintained in the entity with priority and a context.

More information on configuring sales prices can be found in the Developer Docs.

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 taken into account depending on the origin of the order.

The facilityRef stored in the order as the purchaser / receiving facility serves as the starting point for the determination. The ordering facility and its facility group (optional) are "matched" with the different sales prices and the contexts set up here according to their priority. If there is a first match between the contexts, the determined sales price from the listing is included in the cost calculation. By storing a sales price without context, this price-check can be by passed or a fallback value can be stored in case the previous context determination does not 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 of the item.

The calculation of the corresponding discount follows a logic similar to the sales prices.

The contexts set in the discount (e.g., 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 the platform via REST APIs:

  • For the salesPrice and its context: Listings (for different currencies different attributes must be set)

  • For the discounts and its contexts: Discounts

  • For the “mapping” of the purchaser facilityRef: Order

  • For creating categories of an item which can be referred within the listing: Categories

  • For “bundling” facilities: 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.

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 (C&C) orders, the same logic is used. If no explicit currency is provided in the C&C-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.

Transportation Costs:

  • Either package-specific transportation costs on packagingUnitByContext

  • Or fallback transportCosts

Purchase 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 above, 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 Berlin to Customer".

Last updated