Modules:OMS Engine/User Guide
This module provides a webService that can propose the best suitable warehouse/store to fulfill a given order.
The engine will run a set of algorithms in priority order till a solution is reached. These algorithms can be configured in BO as a set of criterias sorted in priority order. The module contains a set of algorithms, and other modules can provide new ones. Each of this algorithms can as well add the required configuration windows tabs and fields. Each organization can determine the set of rules to be used by the engine as well as the priority for each of the rules. Once a rule finds a solution the engine stops executing and next rules are not eval.
OMS configuration window allows defining a set of OMS rules for each organization. These rules are defined in secuential order. The engine will loop through the rules in secuential order till a solution is reached.
OMS Configuration window has two main tabs. In the first one (OMS Configuration) user cans select the organization the rules will apply to. Just one record per organization is allowed.
The rules tab is where to describe the set of rules to be used by the engine for the given organization.
These rules follow a secuential order defined by Line No field. Engine will start with the first rule trying to get the final solution. If the solution is not reached with the first rule, engine will then run the second rule trying to find the solution again. This process continues till the final solution is found. If all the algorithms are run and no solution is found, the engine will return an empty proposal.
Partial Allocation Allowed field determines whether a partial solution is acceptable or not. In case a partial allocation is allowed, the rule can fulfill the order partially, and then next rule will try to attend the remaining quantities for the order.
Each criteria can as well add new configuration fields or tabs. Taking 'Warehouses by priority' criteria as an example, it adds a new tab called OMS Warehouse Priority. That tab can be used to define the different priorities the organization has for each warehouse.
OMS Rule window allows defining a rule as a combination of Criteria in a well-defined order. It represents the list of criteria the OMS rule should take into account to propose the sourcing for an order.
Criteria tab can be used to configure the sequence of criterias the rule needs to eval to get the final proposal.
Engine will use as input the available stock. Each criteria will then transform this input sorting or just removing stock which is discarder by the criteria.
The rule will run each of the criterias in secuential order (See field Line No).
Algorithms can be defined as final. When a criteria is associated to an algorithm declared as final, it has to be the last criteria for a rule. Final criterias output is the one used to fullfill the order, while previous criterias are used to sort or filter the available stock.
Each criteria can as well deploy its own configuration fields. Taking 'Warehouses by priority' as an example, this criteria adds a couple of new configuration fields:
- Priority Lower Than
- Priority Greater than
In this particular case this values are used to filter out the list of available stock for the requested products. The resultant available stock is as well sorted following the priority order of each of the warehouses.
Once this criteria is eval, the oputput si a filtered and sorted list of available stock that can be used as input by the next criteria.
OMS Run window allows monitoring each of the engine execution. Whenever the engine receives a request a new OMS Run record is created. This information is really usefull to understand what the engine did.
The header reports the final status and the time the engine took to process the request. Both Input and Output JSON are as well visible dellow Inpuy & Output section. This are the request JSON (input JSON) and the response JSON (output JSON).
OMS Run window provides a set of tabs to easily track and understand what the engine did.
- Order Lines: This tab holds the information the request is trying to fulfill. It contains the list of products and quantities that the engine needs to deliver.
- Input Stock: This tab holds the avilable stock in the warehouses at the time of the request for the order line products.
- Output Stock: Once rules are executed, input stock is filtered and sorted using the criterias described by each of the rules. The resultant stock is displayed in this tab. This records are the ones finally used to try to fullfill the order.
- Order Proposal: This tab holds the information the engine uses to create the response. This info will be parsed into a JSON to create the final engine response.
- Unable to deliver lines: Lines of the request which could not be fulfilled by the algorithm are displayed here.
- Rule Run: This tab is the one that gives the details of the engine execution. It displays the different rules and the order those rules were executed by the engine.
There are some subtabs which helps us understand what each of the rules did when processing:
- Pending Order Lines: These are the products and the quantities the rule needs to fulfill.
- Rule's Stock IN: This tab is similar to Input Stock tab. It informs about the avilable stock in the warehouses for the requested products.
- Rule's Stock OUT: This is a similar tab to Output Stock tab. Resultant stock after applying the filtering and sorting criterias.
- Criteria Run: This tab adds granular details about each of the criterias execution for a given rule. There all the executed criterias are present. It states the final status and the time consumed by each criteria.
- Criteria's Stock IN: Displays the stock taken as input by the given criteria.
- Criteria's Stock OUT: Displays the resultant stock once filtering and sorting criterias are applied.