You can see how to configure the delivery promise in the Backoffice User Guide.

This section is more detailed and gives information on how the Delivery promise is managed by OneStock.

Overview

To operate and configure the Delivery Promise, two pages are dedicated to the configuration :

Page Configuration > Delivery : To configure the delivery service settings in OneStock
Tab Delivery : To set up methods, dates and route for the Delivery Promise

Delivery promise configuration pages

Delivery Promise : General Configuration

For more information on the Delivery Promise feature, please refer to the following page.

As detailled, the delivery promise estimates the possibility for a fulfillement of the order, and propose the best carriers and associated option, with a final delivery date and the general metrics associated with the delivery (cost, fees, carbon footprint, etc…).

Delivery promise input and output

As a result, before configuring the Delivery Promise service, make sure that the following configuration are already set up :

Stock requests
Sales Channel
Features of Items

Delivery Promise Settings : Configuration > Delivery > Delivery Promise

The configuration page of the delivery promise set up the parameters that will apply for the whole feature. Those parameter will influence how the delivery promise will compute and behave for any call.

Delivery Promise configuration page

{
    "delivery_promise": {
        "recompute_before": 0,
        "stock_requests": {
            "default": "stock_request_name",
            "sales_channel_name": {
                "delivery_method_name": "dp_unified",
                "default": "dp_unified"
            }
        },
        "features_lang": "en",
        "nb_days_to_compute": 7,
        "degraded_mode_nb_days_to_add": 0,
        "ensure_degraded_mode": false,
        "delivery_routes": {
            "default_constraints": {
                "parcel_info": {
                    "l": "maxd2",
                    "w": "maxd1",
                    "h": "sumd3",
                    "W": "sumW"
                }
            }
        },
        "authorized_shipment_number": null,
        "max_additional_nb_days_activity": null,
        "compute_order_eta": false,
        "recompute_cutoff": "best",
        "default_cutoff_for_alert": "best",
        "removed_line_item_states": [],
        "notifications": {
            "order_eta_change": []
        },
        "cutoffs_sets": {
            "use_sort_orders": false,
            "use_sort_orders_for_cutoffs": false,
            "sort_criteria": null,
            "default_sort_criteria": null
        }
    }
}

Stock requests (stock_requests) : Stock requests to use for each delivery

Can be configured in a subpage by clicking on it.

The stock request to use for each sales channel and each method is configured on this page. A default configuration is used in case no sales channel matches the delivery configuration.

Use this configuration page if a dedicated unified stock must be used for a sales channel and a method

Language of product features (features_lang) : Main item features language.

The feature language to use for the delivery restrictions.

The delivery promise can use feature of articles to restrict some promised date. The parameter’s language will be used to define the value

Days of pre-calculation (nb_days_to_compute) : Number of days used to pre-compute the delivery promise

The delivery promise will pre-calculate as much days as configured for on the fly requests.
Beyond these pre-calculated days, the delivery response will be longer. The higher the value, the longer it takes for a delivery promise draft to be published.

Default value for the pre-computation is 7 days. In case precise dates need to be delivered beyond, raise this value.

Maximum number of shipments (authorized_shipment_number) : Number of authorized split for an order

Limits the number of parcel for a delivery. If the delivery requires more shipments than this maximum, the delivery promise will reject the option.
The delivery promise will be quicker if set to a low number. The promise can be computed up to 4 shipments (default value).

Calculation of dimensions and weight of a parcel (delivery_routes.default_constraints.parcel_info) : Shipping feature formula

Can be configured in a subpage by clicking on it.

Computation and dimension to use to estimate the shipping size and compute the delivery cost.
By default the following dimension are used : length = maximum of the 2 largest item dimension, width = maximum of the largest, height = sum of the smallest item dimensions, weight = sum of all items weight.

Cutoffs sets (cutoffs_sets) : Define the way delivery configurations are sorted for the orchestration

Specify the sorting made for the orchestration using delivery promise.
use_sort_orders define if the configured sorting of the delivery configuration must be used (true) or the default one (false)
sort_criteria and default_sort_criteria define what sorting must be made for exceeding date or reachable date. By default it is respectively quickest then cheapest delivery, and cheapest then quickest delivery.

For more information, consult the following page

Notification order eta change (notifications.order_eta_change) : Define the way eta notifications are sent

Specify the estimated date difference before sending the notification.

Parameters allow to compare the new date with the original or with the previous computation
from_original_dp set to true will compare the new date with the original date
from_order_eta set to true will compare with the previous computed date
Only one of the two parameter can be set to true, the other needs to be on false

Parameter duration sets a tolerance difference before triggering the notification. The parameter is in string format and free on the time metric, an additional + can be added to only trigger delayed new date. Eg : +12h for 12 hours delay on the new date, 10m for 10 min difference (early or late)

[
  {
    "name": "{notification_name_for_updated_date}",
    "from_original_dp": false,
    "from_order_eta": true,
    "duration": "+24h"
  },
  {
    "name": "{notification_name_for_original_date}",
    "from_original_dp": true,
    "from_order_eta": false,
    "duration": "30m"
  }
]

To avoid over triggering and only send the notification in case of difference, set a 1s duration by default

Advanced configuration

The following configuration only are available for admin users, please reach your OneStock contact for any changes

Recalculation of delivery promises by stock location : Define the offset time to recompute the delivery promise

Define the time used as a buffer to recompute the delivery promise pre-calculation.

Advanced degraded mode : Use the unified stocks to define the ETA.

If enabled, stock requests will use the highest ETA of unified stock as the detailed stock's ETA parameter. This parameters activation leads to a high cost in performances.

Days to add in degraded mode : Buffer to add to the degraded mode ETA.

The degraded mode is a delivery promise estimation. This parameter allows to add a number of days to the estimation as a buffer.

Calculation of order ETA : Activate the dynamic computation of order ETA.

Every time a change in stocks location, or cutoff exceeding is happening, the order ETA will be recomputed and updated.

Number of additional activity days : Number of activity days to retreive for a stock location.

Default activity days is 7. If a stock location spends more time for a promise activity, this parameter needs to be adjusted.

Delivery Promise : Step by Step configuration

Creation and modification of Delivery Promise is done through the dedicated tab.

Available Delivery Methods, Carriers and parameters can be consulted in the tab using each sub tab.

To modify the Delivery Promise, it is necessary to open or create a draft version.

Once a draft is opened, each parameters can be refined without direct impact on the live version of the Delivery Promise. It is necessary to publish the draft version to apply the modifications live.

1. Define Origins and Destinations : Create zones

To define a origin or a destination, it is necessary to create a zone.

A zone is a geographic aggregation that determines a location where the delivery may happen.

Here are the parameters used for a Delivery Zone :

Zone type
- Unitary : For low level settings of a zone
- Group : For assembled unitary zone
Name & ID
Description
Options
- Country
- Zipcode
- Stock location
- Timezone

Grouped zone allows to gather multiple exclusive unitary zone to create an aggregated one.
For exemple, it is possible to create multiple zones describing districts using zipcodes, and use a group zone that includes all the district to create a zone that constitute a city.

It is possible to include stock location in a specific zone.
If not precised, the adress of the stock location will be used as a zone identifier. It is possible for operationnal purpose to intentionnaly include a stock location in another zone. ex : Suburb located warehouse for a city.

First steps to create a zone

The first zone to create has to be unitary.

Create a unitary zone for a city
Give an explicit name
Define the country and zipcode of the city : “^({zip code regex})”
Create a new unitary zone that exclude the previous zipcode

Tips : Create a zone per specific destination first. Then complete the zone range by adding all the excluded zone remaining

Ex : Cities first, then the rest of the mainland. Abroad territory later.
In the following exemple, Paris will have particular treatment in deliveries (quicker, cheaper etc…). It is a particular zone as a result. The rest of the country has no particularity, France is then created excluding Paris.

The ideal zone range is to have enough zone to cover every particular origin and destination. It is advised to include as much detail as the granularity of the location is necessary for the delivery.

2. Define Operational Steps : Create Operations Optional

Operations are optional. Those parameters will be added steps to the computed cutoff and milestones for the order final delivery date. It allows a more refined and precised promise date.

For each step of an order and shipment handling :

At the creation of the order : At start
ex : Payment, withdrawal time
During preparation of parcels : Shipment
ex : Picking, claim, consolidation, packing
Handling of parcels received by the stock location : Receiving in collection store
ex : Reception, verification
Order preparation direct fulfillment : Fulfillment from collection store
ex : Claim, picking, bagging

The At start operation will always be applied regardless of the stock location that will handle the order.

Duration can be set in from minutes to days for each execution time.

Calendar parameters set up the calendar hours to use to execute the operation. It is possible to include, exclude, or ignore a planning.

For a starting operation, calendars can be selected from the existing opening calendar to precise the obligatory operation to consider for any type of stock location.

Operation calendar can be set using the dedicated calendar button on the Operation tab.

It is adviced to create as much calendar that there is different stock location planning.

Usually, warehouse and stores have different operational hours. Stores may also have different opening hours and date depending on their activities.

2.1 Assign Operational Steps : Stock location Optional

Once operations are created, it is necessary to assign it to stock locations.

Each operation will be adapted to the stock location planning as precised in the configuration, and the computed Delivery Promise final date will be adjusted.

It is possible to apply it massively to different stock location.

First steps to create and assign an operation

Create all the mandatory steps for the shipment step : Picking, Claim etc…
Create an execution time for stores and call it “{Name of the step} - Store”.
Precise the time per operation. Ex : 2h for a picking step in a store.
Repeat the operation for a warehouse.

Tips : Create as much operation that there is mandatory steps first. Refine it later with specific operations to detail the delivery promise final date. Precise the time in the name to easily recognize it late.

Ex : Picking time for a Store, Picking time for a Warehouse, and Claim time are obligatory. Later, add payment time, bag and pack time, receiving and interactions with the carrier, etc…

Assign it to the right stock location using the stock location tab.

In the exemple in the previous gif :

There is a mandatory operation which is “picking”. The time spent will be different for a Store and a Warehouse.

As a result :

We create a calendar for store and warehouse. Stores are open everyday from 9am to 7pm and closed on sunday. Warehouse are opened everyday from 5am to 9pm except on sunday.
We then create the picking operation that we differenciate between store and warehouse. 2h is set up for stores.
We then assign the 2h amount it to our store “main_kt”.

Carrier Configuration

3. Carrier Calendar

For each carrier, a dedicated weekly planning needs to be established to detail the milestone on which the Delivery Promise must be based.

3 type of carrier calendar needs to be set up :

Pickup : Define the weekly slots when the carrier pick-up shipments in a stock location
Transit : Define the weekly planning when the carrier is actively transiting parcels for a delivery
Delivery : Define the weekly slots when a carrier delivers the parcel to an address.

For a single carrier, multiple calendars can be created for a unique step. Depending on contract with the carrier, planning may vary from one zone to another.

For exemple, pickups can be daily for stores in a city center, but bi-weekly on the countryside. Pickups can be made on Mondays on one store, and on Wednesdays on another. etc…

It is necessary to detail as much calendar and steps that there is for the delivery promise to be as accurate as possible.

First steps to create a carrier calendar

Create a pickup calendar for a carrier
- Name it “{carrier} - pickup - {detail slots}”
- Define the weekly slots for the carrier
Create a transit calendar for a carrier
- Name it “{carrier} - transit - {detail planning}”
- Define the weekly working hour for transits
Create a delivery calendar for a carrier
- Name it “{carrier} - transit - {detail planning}”
- Define the weekly delivery hours for deliveries

Tips : Create as much pickup calendar as there is stock location planning specificities. Deliveries and transit hours may vary for one country or region, create as much variation of it.

In our previous exemple :

The carrier will pickup from stores only on Mondays at 1:30pm and Wednesdays at 9:30am.

The carrier will operate in France, which doesn’t allow truck operation on Sundays. Transit time are then created 24/6 excluding Sunday.

4. Carriers Services

The carrier configuration is the core parameters used by the Delivery Promise.

These configurations will be used as component for time computation, carrier metrics, costs calculation. The parameters set on this page will also define which order can be used with which carrier and services.

Configurations are done separately by carrier. The name of the carrier will be the one used in OneStock and received by the Delivery Promise.

Tip : When selecting the carrier logo, OneStock suggest a carrier name. Use the name of the carrier as used in OneStock for a full compatibility of the configuration with other services (Store App, Orchestration etc…).

Once a carrier is created, a configuration page is available to view and define multiple parameters :

Routes and services
Restrictions per service

Routes are meant to be configured by origin and destination zone, and using a specific carrier service.

Once a service is created, a restriction by item feature can be defined in the carrier page. This allows to refine the shipment possibilities with each service.
ex : An express service can not handle out of size items. It can be configured with the length attribute of an item.

When creating a route, 3 elements will be necessary to complete the route usability :

Transit time : Setting the min and max time the delivery is handle

Costs : Depending on the order price, the cost and associated metrics have to be configured

Metrics will be returned as a result if the route is selected by the delivery promise

Constraints can be detailled to split costs and values depending on a parcel feature
Ex : Carbon footprint is 0.59 kg CO₂e for parcels under 0.5 kg but it is 1 kg CO₂e above 0.5 kg

Carrier planning : Assign a carrier calendar to the route.
Adapting the selected carrier planning to the route is key for the right computation of the delivery promise. A carrier with express service will probably have a more active pickup planning. For a country, the transit planning might vary.

First steps to create a carrier route

Add a new carrier
- Name it (preferably with a OneStock compatible name)
- Select the right logo
Add a new route
- Select the origin and destination zone
- Create a new service.
  Name it with the one as a carrier service code (that needs to be in the request)
Define the minimum and maximum attributes for the transit time
Define costs
- If a differenciation needs to be done by order price, add a cost table constraints
- Add criteria for each separation
- Detail the cost for each specificity
Define the calendar to apply for the service for each steps

Delivery Promise Crafting

The delivery promise configuration is the final step to build a responsive call.

It relies on 2 essential elements of the delivery promise configuration which are : The delivery configuration and the delivery method.

5. Delivery Configuration

All available configurations are listed in the delivery configuration tab.

Configurations are detailed by delivery methods, sales channel and destination zone.

Using the add configuration button a popin allows the creation of a new configuration.

For each configuration, an order type allows to differentiate the configurations.

A delivery method needs to be set for each configuration.

Tips :

Choose a usable id for the delivery method as it will be used for API calls
Delivery methods are meant to be re-used from one configuration to another. Don’t hesitate to put a similar delivery method with different parameters.
Eg : standard with different sales channel or delivery zone

Once a delivery method is created, different parameters needs to be set to complete the configuration.

Stock queries : Stock query to use to retrieve availability
Carriers : Carrier and services concerned by this configuration
Optional Operations : Mandatory executed operation for this method
Priorities : Metric and cost sorting that will be done for the answer

First steps to create a carrier configuration

Choose the order type
Define the delivery method
- Name it with an API compatible ID that is reusable
Define the stock request
Define the configuration parameters
- Concerned Sales channel
- Destination Zones
- Carrier + option
- Operation
- Priorities

In our previous exemple :

The standard method is configured : Multiple carriers allows this type of delivery method UPS and DHL.

2 operations are mandatory and will be used to refine the delivery estimation date.

As it is a standard delivery, delivery date is not the highest priority. The sorting is made on eco friendly routes, date, and cost.

Verification

6. Test

The delivery configuration can be tested on specific parameters to ensure the methods deliver a correct estimation.

The test is done using :

Articles
Destination
- Detailed address, zone, or specific stock location
Sales channel
optional Price
optional Unique delivery method
optional Date

Tip : Before publishing a configuration, ensure the delivery is running as expected.

Once a configuration is published, it affects live requests.

Delivery Promise Configuration