Orchestration - Sorting and capping of candidates
- 1 Sorting of candidates
- 1.1 Principle
- 2 Max candidate
- 3 Expected behaviour
- 4 Use the Max Candidate Option for Sequencial orchestration
- 4.1 Guide to configuration
- 4.1.1 a. Ruleset Chaining
- 4.1.2 b. Custom trigger
- 4.1 Guide to configuration
Sorting of candidates
Candidates can be sorted using the “Number of candidates” option in the ruleset configuration.
To access the criteria to sort the stock locations, define a max in the number of candidates option. A criteria button will appear allowing to define how the endpoint will be sorted.
Several options are possible to sort the stock locations. These options are applied individually on each stock location.
3 parameters are applied : Sort criteria, order and threshold.
Criterias for the sorting are the following :
Order being prepared : dynamic tag claim_nb - Number of order in preparation in the stock location
Distance : relative distance to delivery address
Stock coverage : number of article available for the stock location, relative to the number of article considered. (if no sales on the period are imported : stock coverage = sum( stock(articles) ) / nb (articles) )
Reliability : dynamic tag reliability - Number of order prepared in relation with the number of order claimed and unclaimed
Order proposed : dynamic tag generate_candidate - Number or ordered proposed to claim
Packing time : dynamic tag preparation - Average time spent to prepare an order
Order of the sorting can be set to ascending or descending. Depending the business objective, the right order needs to be configured.
Example : If the objective is to reduce the global stock coverage of articles in all stock locations, the sort criteria stock coverage will be set to “Descending”. On the other hand, if the objective is to completely empty the stocks and reduce the number of stock location involved, the sort criteria stock coverage will be set to “Ascending”.
Threshold is used to define the comparison step to use for sorting based on range of values. It is used for refine the granularity to sort each stock location.
Example : If a reliability criteria is used, a threshold of 1 will considered 90.0% and 90.4% as equal.
Principle
Sorting criteria is applied individually on each stock location. Candidates are not taken into account as a complete solution in the sorting.
This can result in a sorting of stock location were a solution is split on a large range : Exemple, stock location A is the best regarding the criteria, but need to be associated with stock location Z to complete the order. The sorting remains : A > B > C > (…) > Z
Sorting criterias are used sequencially in case of equality. No combination of criterias are possible for a sorting.
If a combinaison is necessary for business purpose, we advice to use a larger threshold to simply consider an equality to use the second criteria.
Example :
Sorting on criteria 1 : A > B = C > D
Sorting on criteria 2 : D > C > B > A
The sorting will be : Stock location A > C > B > D
Max candidate
Number of candidates can be capped to a max number.
This option allows to limit the number of stock locations able to claim an order in order to control the competitivity aspect of a rule.
For example, it is possible to propose an order to a certain number of candidates for a limited period, before increasing it for the next rule.
Note that the option max candidate is not blocking for the rule : we may have more candidates as an output result to respect the filter.
Principle (sequence in the orchestration)
Here is a diagram of the first steps of an orchestration using a ruleset. Filters are first used to generate candidates, later, options are applied on the batch of stock location of the output.
There is a strong dependency between the max candidate option and the filters applied for a ruleset.
The filter will be first applied to create a batch of candidates, then the option max candidate is applied while trying to respect the filters used before.
When configuring a max candidate, check that the filter and the max candidate option are compatible
Some filter such as “at least one” stock locations, associated to source number may, be antagonist to the max candidate targeted.
We recommand using the source value as the lower limit for the max candidate to ensure split compatibilities
Example :
With a compatible filter
Filter : Source <= 2
Orchestration generation : Stock location A, B, C, D, E
Max candidate = 3 sorted by reliability. Sorting is A > C > B > D > E
Output : Stock locations A, C, B are candidates.
Without a compatible filter
Filter : Source <= 2, at least one stock location is a warehouse, at least one stock location is a store.
Orchestration generation : Stock location A, B, C, D, E. Every stock locations are stores, B is a warehouse.
Max candidate = 2. Sorting is A > C > B > D > E
Output : Stock location A, C and B are candidates.
On this example, we generate a solution with a warehouse AND a store. But we expect only two candidates that will respect the filter.
As it is impossible, the orchestration still offers candidates to fulfill the order within the filter constraints, even if we exceed the max candidate. More details in the split behaviour section.
Expected behaviour
Here are some use case example and the associated behaviour of the orchestration.
Set up a maximum of candidate with a simple sorting
1. Use the sorting to control the automatic claiming
In the following example, we set up a new ruleset with the rule 0 • Max candidate rule
The filters are used to define a single source for the order, which is a warehouse.
Then a maximum candidate of 1 is set up to access the sort criteria. The sorting of candidates is done per stock coverage.
Finally, the activation of automatic claiming is done toward warehouses.
Here the number of max candidate doesn’t really matter. We only have 1 source and an automatic claiming. The order will be assigned to a single warehouse in any case.
Purpose of the rule : We want to assign the order to the warehouse with the highest stocks.
Knowing that we start the orchestration with a stock coverage that is the following :
WH = 100 units
WH2 = 90 units
WH3 = 2 units
The sorting should then be WH > WH2 > WH3. We then expect the stock location WH to be selected by the orchestration to handle the order as it is the best candidate on the sorting.
2. Use the max candidate to control the competitivity
In the following example, we set up a new ruleset with the rule 0 • Max candidate rule
The filters are used to define a single source for the order, any stock location is considered.
Then a maximum candidate of 1 is set up to access the sort criteria. The sorting of candidates is done per stock coverage.
A timeout of 5 min is defined, to allow no competition for a limited period
On a second step, we set up a new rule 1 • Max candidate extended
The filters are used to define a single source for the order, any stock location is considered.
Then a maximum candidate of 5 is set up to access the sort criteria. The sorting of candidates is done per stock coverage.
Here the number of max candidate matters. We only have 1 source, but we want the sequential rules to set a limited number of candidates first, then to propose to more stock locations to increase competition.
Purpose of the rule : We want to the orchestration to target stocks first, then include more competitivity for the order fulfillment.
The stock situation should prioritize first our stock location with the most stock (here WH), then propose all the following stock location as candidates on the second rule.
As expected, WH is the only candidate first.
The number of candidate then extends to the targeted maximum :
Splitted orders1. Use the max candidate to control the competitivity on splits
In the following example, we set up a new ruleset with the rule 0 • Max candidate rule
The filters are used to define less than 2 sources for the order, any stock location is considered.
Then a maximum candidate of 3 is set up to access the sort criteria.
The sorting of candidates is done per reliability
Here we expect 1 or 2 sources possible. Depending on the sorting at the moment of the orchestration, combinaisons of stock locations can be made.
Be aware that the more the items or sources, the more complex the combinaison of possible candidate can be done. Our Max candidate output doesn’t take the combinaison into account as a result.
Purpose of the rule : We want the ruleset to handle a split solution and to only propose a target number of candidates.
Here is the the sorting of stock location per reliability
Here is the stock disposition for each article in the order
As we see on our stock, we expect at least WH to be in the set of candidates. The next stock location for the split will depend of the sorting.
After the orchestration run, we do find only 3 stock location as candidates
As expected, the first 3 with the highest reliabilty are included.
From that moment, if one of the 2 candidates claim the only article shared, we do observe that the number of candidates is updated to the only remaining one.
In the following, the Store 1 claims the first item. WH2 was also a candidate for this article.
Our orchestration ensure that even with a split and a partial claim, the order is still proposed to the sorted candidates and within the possible solution for the split.
2. Atypical configuration and behaviour with splits
Split is mandatory to fulfill the order
In the following example, we set up a new ruleset with the rule 0 • Max candidate rule
The filters are used to define less than 2 sources for the order, any stock location is considered.
Then a maximum candidate of 1 is set up.
The sorting of candidates is done per reliability.
Here we expect 1 or 2 sources. Depending on the sorting on the moment of the orchestration, combinaisons of stock locations can be made.
Purpose of the rule : We want the ruleset to handle a split solution and to only propose one candidate for the order (completely or partially handled).
Here is the the sorting of stock location per reliability : WH > Store1 > Store2 > Store 3 > Store4
Here is the stock disposition for each article in the order : Split is mandatory for the order to be fulfilled
After the orchestration, we observe that 2 stock locations are proposed.
To fulfill this order, a minimum of 2 stock location must be candidates. The option is set to at most 1 candidate which isn’t a viable solution to complete the order.
The rule may offer a candidate if we have a unique stock location able to handle the order by itself.
On another hand, the rule can propose more candidates if the number of sources is mandatory.
To generate candidate in this situation, the max candidate must match the number of source
The filters are used to define less than 2 sources for the order, any stock location is considered.
Then a maximum candidate of 2 is set up.
The sorting of candidates is done per reliability.
The filter doesn’t match the sorting
In the following example, we set up a ruleset with the rule 0 • Max candidate rule
The filters are used to define less than 2 sources for the order, at least one warehouse is considered as a result.
Then a maximum candidate of 3 is set up.
The sorting of candidates is done per reliability.
Purpose of the rule : We want the ruleset to handle a split solution and to only propose a target number of candidates.
Here is the the sorting of stock location per reliability : WH > Store1 > Store2 > Store 3 > Store4
Here is the stock disposition for each article in the order : A split is necessary to handle 2 quantity of the article
The sorting criteria is used the descending way
After the orchestration run, we do find only 3 stock location as candidates : The max candidate number is respected
As our sorting is descending, the order is the following WH > Store1 > Store2 > Store 3 > Store 4
The orchestration picks WH, Store1 and Store2 as they have the best reliability, the filter is respected with 2 sources and one warehouse.
The sorting criteria is used the ascending way
After the orchestration run, we do find only 5 stock location as candidates : The max candidate number is not respected
As our sorting is descending, the order is the following Store4 < Store3 < Store2 < Store1 < WH.
The orchestration generates candidates respecting filter, the sorting order, then targets the maximum number of candidate.
As it can’t keep the targeted number without breaking the filter constraints, or the sorting integrity. The resulting candidates number is extended to match the filter constraints.
To avoid these two atypical behavior our recommandations are :
Match the max candidate value with the number of sources
To avoid as much as possible “at least one” stock location filters when sorting candidates
Use the Max Candidate Option for Sequencial orchestration
OneStock orchestration is built for competitivity and is made specifically to propose the order simultaneously to several stock locations.
Some business use case may require to propose the order to stock locations on a sequencial manner.
As it is not a core method for OneStock’s orchestration, the configuration is not adjusted to set up this type of scenario.
However, there is a configuration allowing to replicate a sequencial orchestration using your favorite OMS.
In the OneStock alternative method for sequencial orchestration, the order is proposed to a number of stock location during a limited period, then the candidate are removed, and updated to new ones.
A stock location will never be candidate multiple times, only once.
Guide to configuration
Start by accessing the orchestration configuration tab, and open the targeted ruleset that you want to use.
Once the ruleset is selected, only one rule is necessary to configure this orchestration method. Create a new one.
The first 2 filters are mandatory, then the option for limiting the number of candidates can be configured.
Define the source number
The source number allows to define the number of split tolerated on the sequence.
The source number plays an important role to define the considered stock location for the temporary proposal.
Use the mandatory filter
The filter “Has not yet been a candidate” allow to only generate new candidate on the rule orchestration.
The filter has to be used on every rule of rulesets for sequencial purpose. It allows to recall and remove previous candidates. This filter ensure a renewal of the candidates at each computation.
If you want to use multiple rules, the filter needs to be set on each one.
Limit the number of candidates
In order to propose the order to stock locations with few or no competitivity : Max candidate needs to be set as well.
In this example, we want to propose the complete order to unique stock location. (Source = Max candidate = 1)
As precised previously, make sure the split is considered in the capping of candidates.
Choose a sorting that will match the filters to avoid atypical candidate output.
Define the sequence activation
The rule now allows to generate a limited number of candidates, that will change at every orchestration.
The mecanism only allows as much sequencial candidates re-computation as you have rules. To control the re-computation, 2 ways are possible : Ruleset chainings, or Custom triggering.
a. Ruleset Chaining
The ruleset chaining allows to use the previously configured ruleset to set up the sequencing. The exclusion will be consistent between each use of ruleset.
Easily configure the sequence
Control the number of candidate computation
Possibility to switch from a sequential orchestration to a competitive orchestration
Does not cover the complete range of candidates without setting a rule per computed candidate (or batch of candidates)
b. Custom trigger
The triggering of the orchestration can be done using the orchestration computation API.
Using this route with the field reset_previous_candidates set to false allows to renew the candidate for the ongoing rule.
Using a custom script would allow a complete control of the process to change the order candidate.
This method allows to cover the complete range of candidates for an order “automatically”. The re-orchestration needs to be stopped when no candidates are found (on the rules over event).
For exemple, with a custom script in the integration layer, a computation of new stock location candidates could be done every hour. By retreiving the orders in the orchestration status and calling the API every hour.
Freedom of triggering criteria
Complete cover of potential candidates
Requires development effort