Most Powerful Open Source ERP

Simulation Motos

Some data about Simulation Motos.
  • Last Update:2016-05-16
  • Version:001
  • Language:en

Some data about Simulation Motos

Table of Contents

Delivery Properties

1- each time a property or category can only be set at the order / delivery level it is most often a design mistake

2- any property which can be used to split / group movements must be defined on delivery lines / movements and acquired if necessary from parent delivery / delivery line

3- any property which can be the cause of divergence must be defined on delivery lines / movements and acquired if necessary from parent delivery / delivery lines

4- any property which can be the explanation of a split or merge request of deliveries (implemented through target solvers) must be defined on delivery lines / movements and acquired if necessary from delivery / delivery lines

Conclusion: most if not all order properties will be movement to movements. This includes specialise, causality, etc.

getProperty and edit

The main purpose of getProperty and setProperty in ERP5 is to

1- act as helper to edit

2- mimic Zope original behaviour for property handling

An example was brought in which calling getPropery('specialise') was not giving the same result as calling getSpecialise(). In that example, getSpecialise(), as a method was acquired from parent object, then returned the value on the parent. getPropery('specialise') was just returning the local property of the document (None).

Is this a bug or a feature. It is a feature. Why ?

1- implicit acquisition will be removed some day, you can not rely on it in this case (unlike in the early days of ERP5, where it was used a lot for indexing=

2- we do not want self.edit(specialise="whatever") to modify the parent object of self.

3- we want self.getProperty('specialise') to be consistent with self.setProperty('specialise')

Fastest Expand

Whenever expand is called on different applied rules of the same root applied rule, there is. a risk of reexpanding many times the same subtrees of the simulation tree, not to mention the risks of ZODB conflict.

Proposed solutions to handle this:

- always reexpand from the root applied rule. This is great for small simulation trees but fails on large ones.

- always reexpand from a child of the root applied rule. Similar.

- always rexpend a single applied rule at a time, without forwarding, and forward expand as an activity. This is best to expand large simulation trees in parallel. But could be slow.

Which is the best? Still unknown.

Related Articles