With cleaning matrices you can determine whether cleaning should take place or the to be loaded product is forbidden with a previous loaded product.
Go to F11 -> Cleaningmatrices
The period indicates from when the matrix is active. So when a new matrix is available, it must be re-entered with the date from which it is active.
The rows (product to be loaded) and columns (previous product) of the matrix are in a specific order. The order can be changed by selecting a row or column and use the shortcuts [Ctrl + Up] or [Ctrl + Down].
The operation is as follows:
The product to be loaded is evaluated against the first rule (matrix row). If it matches, the previous product is evaluated against the matrix columns, else the second row is evaluated. And so on.
If no match is found and a diagonal result is defined, the previous product is evaluated against the row from step 1. This is a shortcut e.g. to define that if product and previous product are the same no cleaning is needed.
If no match is found and a last resort result is specified, this is used.
A product can be specified by choosing a type and choosing an entity or entering a code.
If a code is specified it can be entered as a LIKE – expression.
Here you choose the rows and the result:
Besides that the result is a cleaning yes/no, the result can also be another matrix. This enables you to make the setup more logical and efficient. And more in line with how the customer supplies the matrices. E.g. you have a customer which supplies different matrices for different product groups. In this case you can make a ‘matrix’ that results dependent on the product group in specific matrix for each product group.
Below is an example of how a matrix is supplied by a customer:
To interpret the matrix, simply find the product to be loaded in the left-hand column of the table and then read across to the columns to the right-hand of the table until crossing the previous product loaded for that particular tanker. This will indicate whether or not cleaning is required. For any other pre-load than mentioned in the below matrix, cleaning is always required.
Note that due to the exception in group “Glucoses”, group “Glucose/Fructose” is placed as first.
Furthermore groups “Fructoses” and “Glucose/Fructose” are merged since they have the same result.
For groups with seqno 2, 5, 6, 7, 8 and 9 nothing is specified as previous product. This is covered by the diagonal result. The sentence “For any other pre-load than mentioned in the below matrix, cleaning is always required” is covered by the last resort result.
The field “Fixed customer” can be used to use the matrix for different customers which use the same matrix but you have only defined product codes at one customer. Applies only when the description of the entity type contains the word “customer”.
Loading and unloading addresses are extra conditions that can be used. E.g. a customer only considers a previous product to be the same if it was loaded on their site.
The maximum number of reloads (loadings without cleaning in between) and / or the maximum reloading days can be defined in the cleaning matrix. These can be defined in a general way on (previous) product level.
When planning loads this will be checked and when one of these constraints are violated a warning will be shown.
Testing the cleaning matrix is possible by the lightning icon. A new window opens to perform a simulation by the product to be loaded and the previous product and possible other conditions. The simulation shows the result & -type as well as the path followed to the result presented.