How to do the "expand" method.
Table of Contents
The key issue is to make the "expand" method stable so that it is possible to reexpand any simulation tree at any time with predictable result. For this purpose, we need to
control what to do for any divergence between simulation movement and delivery movement and simulation movement and order movement too.
So we decided not to use 'order' category on simulation movements.
AR (Order Rule)
+-SM (order:Sale Order Line, delivery:Sale Packing List Line)
+-AR (Invoicing Rule)
+-...
AR (Order Rule)
+-SM (delivery:Sale Order Line) <-- NEW
+-AR (Deliverying Rule) <-- NEW
+-SM (delivery:Sale Packing List Line)
+-AR (Invoicing Rule)
+-...
For the compatibility, existing simulation tree works as it is.
The expand process has to be able for any applied rule to generate
- a list of simulation movements to update (and which properties to update)
- a list of simulation movements to delete
- a list of simulation movements to add (either to compensate existing ones or add new ones)
This process is rather simple before any delivery happens:
- a matching method is used to match existing simulation movements generated by the applied rule and those already present inside the applied rule
- simulation movements to update are fully updated
- simulation movements to delete are deleted
- simulation movements to add are added
- there is no need to do any compensation
However, if simulation movements are delivered, the process becomes more complex:
- some simulation movements are frozen and need to be compensated in case the applied rule has evolved (ex. change of transformation, of tax, etc.) or if properties of parent
movements have evolved (ex. date, quantity, resource)
- simulation movements may differ from what the applied rule generates (ex. different resource, date, etc.) yet we do not really want to change the properties on the simulation
movement either because of a previous divergence decision (ex. replace resource R1 with resource R2) or because the difference is not big enough to compensate an existing frozen
movement (ex. change of date by 1 hour) or because we want to keep using the property of the delivery rather than the property provided by the applied rule (ex. minimal change of
date, minimal change of quantity).
The considered solutions are based on the following ideas:
- define a matching key made of properties. Ex. resource, variation, industrial_phase
- define a matching method between keys. This matching method can be equality (simple) or approximate equality (ex. about same quantity) or more complex (ex. not later than 1
day after, not sooner than 10 days before). This means that the matching method is not symmetrical. This matching method is probably related to divergence testers (more work
required on this assertion).
- use this matching key and method to match simulation movements generated by the applied rule with simulation movements stored in the applied rule
- each time a solver is called to "force a property" (ex. change of resource), record the original value of the property (ex. R1) and use that original value for following
matching key calculations instead of the new one (ex. R2). "Forced properties" are also ignored at update time (i.e. no update happens).
- use properties defined on the delivery rather than those defined on the simulation movement (they can be different, yet within the range allowed by divergence testers) in
children applied rules.
- before compensating frozen delivered movements, make sure that applicable divergence testers make this compensation relevant.
- before updating non frozen delivered movements, make sure that applicable divergence testers make this update relevant.
Source Code¶
Divergence Testers have been identified as the core location to define a matching API.
Related Articles¶