Stock locations queries

Guidelines

Creation of a new query

To create a new query, click on the button “Add a stock location query”.

You'll need to give it a name, and then decide whether you want to inherit it from an existing query or not. Once the query has been created, you are automatically redirected to its details.

Then, you will be able add filters to define the scope of stock locations. There are 7 filters available on stock locations :

Type

This filter is used to filter on the stock location type (usually store or warehouse).

The stock location type is managed in its “manual tags” section in the backoffice.

Manual tags

This filter is used to filter on one or more manual tag values defined on the stock location.

If several manual tags are added, the stock point must respect all of them in order to be returned by the query (the operator is always AND).

Manual tag values can be updated in the stock location page or by importing an "endpoints" feed.

To create a new manual tag, please get in touch with your Onestock contact.

Enabled modules

This filter is used to filter on enabled or disabled modules on stock locations. Operators AND or OR can be used in the filter.

Stock location list

This filter is used to filter on a hard list of stock locations.

If other filters are added, the stock locations will have to validate the other criteria to be returned by the query.

Order in Store Sales channel

This filter is used to filter on the "sales_channel" field stored into the endpoint. This sales channel is only used for Order In Store and given at the order creation.

Country

This filter is used to filter on the country the stock location. The country is stored in the field "address.regions.country.code"

Scheduled event options

This filter is used to filter on options activated on stock locations, that may be affected by scheduled events.

Claim : If enabled, stock locations in an exclusion period in their calendar or affected by a scheduled event will not be returned by the query.

Stock export : If enabled, stock points affected by a scheduled event will not be returned by the query.

We recommend that you systematically activate this option on stock export queries, so that scheduled events are systematically taken into account.

Onestock advices

We advise you to use inheritance to build your queries.

First of all, we advise you to start with an unfiltered query called stock_locations. This query will always return all stock locations.

Then, queries can be separated into stores and warehouses using the "type" filter

Stores

In stock queries, we'll need to differentiate stock locations according to their activated modules, to know whether they'll be able to satisfy the order. The 3 main module characteristics are:

  • stores_sfs : to filter on stores with Ship From Store module enabled

  • stores_cfs : to filter on stores with Collect From Store module enabled

  • stores_cfs_not_sfs : to filter on stores with Collect From Store module enabled but Ship From Store module disabled.

These stock locations queries will be used in the orchestration stock queries to cover all possible cases. Here's an overview of the logic:

  • If the order is for home delivery: since all Ship From Store enabled stores will be able to prepare and ship the order, then we'll use a single stock aggregate with the stock locations query stores_sfs, regardless of whether their other modules are activated.

  • If the order is for click and collect express: only the destination store will be able to prepare the order if it has the stock, so we'll use a single stock aggregate with the stock locations query stores_cfs, regardless of whether their other modules are activated. Another parameter will filter only on THE destination store.

  • If the order is for standard click and collect: two different groups will be able to prepare the order. Firstly, all SFS stores because they will be able to ship to the destination store, then we'll use a first stock aggregate with the stock locations query stores_sfs. Secondly, the destination store itself. But since we don't have to count it twice if it is SFS enabled, we'll use a second stock aggregate with the stock locations query stores_cfs_not_sfs.

Then, we advise you to separate SFS requests by country or sales channel. Most of the time, orchestration rules will differ from one destination country to another. In our example, we separated by fr and uk countries to build stores_sfs_uk and stores_sfs_fr queries.

Finally, we advise you to differentiate the SFS stores eligible for stock export. The only element to modify in relation to the request used by the orchestration is the “Scheduled event options” parameter. You will need to filter on stores eligible for stock export, so that those affected by a scheduled event will not be taken into account. In our example we have created the stores_sfs_fr_export and stores_sfs_uk_export queries.

Warehouses

We assume that warehouses only dispatch products and are therefore never eligible for Collect From Store. However, they can be declared as active or inactive using the Ship From Store module. This is why we recommend creating the query "warehouses" by filtering on the stock location type, and then the query "warehouses_sfs" by filtering on the SFS module.

In our example, we assume that warehouses can ship to all countries, but if this is not the case, we'll need to create different stock queries to differentiate.

Finally as for stores, we advise you to create the warehouse_sfs_export query to differentiate warehouses eligible for stock export by adding a filter on “Scheduled event options”.

Example

This is what our stock point query tree looks like.