General Presentation

The Movement class allows to implement ERP5 universal accounting model.

Movement instances are used in different situations:

• Orders: Movement instances are use as a documentary object to define quantities in orders
• Deliveries: movements track the actual transfer of resources in the past (accounting) or in the future (planning / budgetting)

For example, the following objects are Orders:

• a purchase order (the document we send to a supplier when we need some goods)
• a sales order (the document we ask our customer to sign to confirm a sale)
• a production order (the document we send to the workshop to confirm we need some operation / service to be achieved)

Orders allow to describe a target, but can not be used to account the reality of actual transfered quantities.

This is not the case for Deliveries:

• an invoice (a delivery of money between abstract accounts)
• a packing list (ie. a delivery of goods shipped)
• a delivery report (ie. a delivery of goods received)
• a production report (ie. a delivery of service)
• a T/T report (a delivery of money between reals accounts)

For simple planning, we use a simple approach. Deliveries contain a reference to an order (causality) 2 quantities:

• a quantity value
• a target_quantity value

When quantity and target_quantity, the delivery can be closed. When quantity and target_quantity is different, a new delivery is created with 0 quantity and target_quantity = target_quantity - quantity. This simple system allows to delivery goods of a single order in multiple times, and to keep track of deliveries without any complex planning system. It is the basis of ERP5 trade module.

If we need to implement more complex planning, such as in a production workshop, we can not use such a simple model. We have to implement a planning system. The approach in ERP5 is based on "simulation".

In this case, target_quantity becomes meaningless.

For complex planning, the following approach is used instead.

1- Movements from an order are never modified once the order is confirmed. This is a rule. An Order is like a contract. It can only be amended, if all parties agree.

2- Movements in a delivery may exist on their own (ex. an accounting transaction). Past movements can not be modified. Future movements may or may not be modified

When an order is confirmed, the list of "order" movements it contains is copied into "delivery" movements. Each delivery movement contains a "causality" reference to the order it. This allows delivery to be completely different from order (ex. different resource, different date, different quantity) and allows to keep track of the causal relation between a delivery and an order.

A delivery document then points to one or more of the "delivery" movements in the simulation. It is possible to know which items have been delivered by making sure each movement in the simulation is associated to a "delivery document".

By looking at all "simulation"

Delivery movements can be applied the following transformations:

• split : one movement is cut into 2 or more movements
• submovements : one movement "generates" many other movements. For example, a delivery of goods from the workshop to the stock, will result in a "pull" calculation which generates operations and sourcing based on a BOM document. The causality of each delivery is the "applied rule" which was used to generate submovements

One should note that

• movements are never joined (because it would breack causality and tracability)
• movements acquire some context information from their causality

Some submovements need no order to be "confirmed". Some submovements need an order to be "confirmed". For example

• a submovement which allows to compute the CO2 emissions of a production facility needs no order confirmation (this kind of movement is mostly ised for reporting)
• a submovement which takes some goods in a stock and brings them to a workshop needs some "stock movement" order to be "confirmed"
• a submovement which requires someone to take his time for some operation nees a "service order" to be confirmed

This means that the simulation process must make a distinction between different workflows applicable to a movement. For movements which require an order to be confirmed, the workflow involves the following steps:

• an order is automaticaly generated, with "order movements" which become "causalities" for delivery movements (XXX this sound strange...)
• each order movement is associated to one of the delivery

As a result, a delivery movement which requires an order may have 2 causalities

• one causality (ie. application of a rule)
• another causality (ie. confirmation in an order)

Each causality may define its own context. One context may be related for example to a customer request, another context may be related to an "internal customer" request (eg. the production manager). Context may eventually conflict each other.

In a customer oriented company, movements should probably always be stored within the customer order and acquire from the order all context information.

In a mass production facility, context may be defined in more than one location. This is an incentive for putting all movements in a simulation "box".

The second approach is chosen for documentary consistency approach : in ERP5, documents rules, can be synchronized. Simulation can not be synchronized

Process Presentation

Simulation Directory (S)

Contains Applied Rules (A) which contain Simulation Movements (M) which contain applied rules....

Calculation rules

• expand updates target dates and quantities top down
• if a simulation movement is associated to a delivery movement
  • quantity defined locally
  • start_date and stop_date acquired from Delivery (start_date of S acquired from start_date of D, stop_date of S acquired from stop_date of D,)
• if not
  • quantity, start_date and stop_date acquired from target values
• if a simulation movement is associated to an order movement (OrderRule)
  • target_quantity, target_start_date and target_stop_date acquired from order target values
  • unless local target values have been defined
• if a simulation movement is associated to an order movement (OrderRule) and to a Delivery movement
  • target_start_date and target_stop_date locally defined
  • target_quantity locally defined

Deliveries (D)

A container of Movements aggregated from the Simulation.

User is allowed to change target_quantity, target_start_date and target_stop_date in the user interface. It has no consequence on the Simulation of values.

Delivey isDivergent whenever target values and value are different. Delivery automatically changes its state to diverged.

User may confirm that Delivery should adopt new target values (and that the simulation should adopt new values for quantity, start_date and stop_date). In this case, user may chose a DSolver (D as in Delivery) to distribute new quantity values accross Simulation Movement quantities. Simulation movements acquire new dates from the new start_date and stop_date of the Delivery, defined after the target values of the Delivery. The DSolver makes the Delivery consistent again.

An ASolver (A as in applied rule) must then be applied to parent rules of movements related to the Delivery, so that new targets are defined based on the new quantities changed by the DSolver. This process is a bottom-up process (it eventually changes target values of parents, or adds movements to compensate inconsistency of an Applied Rule).

During that process, new target values defined upwards may be inconsistent with values defined in deliveries. ASolver is responsible for updating target values of Deliveries (thus making such deliveries inconsistent) and to continue upward the update of target_values. The whole chain of applied rules will then be inconsistent with proposed new target of deliveries.

Whenever an applied rule updated by a DSolver is consistent without requirement for an ASolver (or if ASolver makes it consistent ?), expansion can take place and forward new target values downwards. The expansion process works on targets and goes from top to down. During the expansion process, changes of target values may require to update more target values of Deliveries.

ASolver vs. DSolver

DSolver changes values in the Simulation. It implements in the Simulation decisions of Deliveries. It defines new values which represent the expected reality.

ASolver changes targets in the Simulation. It defines new targets & movements which allow values and target values to match in the simulation. It either changes a target value (more, less, before, later) to meet a rule, or adds movements to compensate for unmet aspects of a rule.

Expansion Process

Applied rules expansion defines new targets:

• A diverged rule must be solved
• A solved rule must be expanded
• An expanded rule can be expanded (again)

During expansion, some movements may be divergent (ie. target and values differ if movement is associated to a delivery):

• A diverged movement must be solved. Target values are automatically set in the Delivery to adapt values in the movement.
• A solved movement must be expanded
• A expanded movement can be expanded (again)

DSolve Process

The DSolve process defines new values at a given point of the simulation. (on movements)

If a movement solved by DSolve is not divergent anymore, expansion takes place immediately after DSolve. Else, ASolve takes place immediately after.

ASolve Process

The ASolve redefine new targets from bottom up.

• A diverged rule must be ASolved.
• A non parent solved rule must check if its parent rule is stil consistent.
• A parent solved rule must be expanded.

ASolver has 2 different modes

• Delivery Mode: values of a given movement are taken into account to calculate new target of parent (or additional movements). Previous target values of parent is stored in a previous target temporary structure. This happens after a DSolve.
• Automated Mode: previous target values are taken into account to calculate new target of parent (this is the general case)

Once the ASolve process is finished, an expansion process defines new targets downwards.

Simulation Movements (M)

Whenever target values and values are different, a movement is said to be divergent. Divergent movements must be solved.

Movements not attached to a delivery movement never need to be solved. (ie. values acquire target values).

Only movements related to a delivery may need to be solved. Solving movement may only happen in the DSolve process.

Applied Rules (A)

At any time, some applied rules may be divergent. It is the responsability of the rule to define the meaning of divergence of child movements.

An order rule is divergent whenever target values and values differ in child movemements.

A transformation rule is divergent whenever target values and values differ in child movement or when target quantities in child movements do not allow to produce the required target quantity in the parent movement.

Solving divergent applied rules is implemented by showing a list of deliveries which movements relate to child movements of divergent applied rules. Presentation uses (if possible) trees which mimic the causality chain of the simulation.

Solving applied rules require to define new targets. The choice is driven by the deliveries and a user choice of ASolver. It is mostly automated.

Inconsistent Deliveries

Some target values in deliveries may be equal to current values of the delivery but inconsistent with target values in the simulation. This is another case of divergence. The simumlation process should automatically update target values of the delivery to new target values of the simulation. Either user adopts new target values in the Delivery (easy) or use forces back existing values. The latter case requires the use of a DSolver.

What happens if...

If the default_target_start_date is changed in a Delivery

A DeliverySolver instance may copy the new target_start_date to start_date of simulation movements related to the delivery.

New start_date is propagated upwards by TargetSolver instance (for example, to postpone the whole production).

New target is propagated downwards by expand (for example, to postpone delivery of sourced material)

If the default_target_source is changed in a Delivery

A DeliverySolver instance may copy the new target_source to source of simulation movements related to the delivery.

New target_source is propagated upwards by TargetSolver instance (for example, to change a production site in order to comply with new shipment site of goods required for production).

New target is propagated downwards by expand (for example, to set all sourcing at the new production site)

If the resource is changed in a Delivery Movement

propagateResourceToSimulation is activated on the delivery.

If the variation range is changed in a Delivery Movement

propagateResourceToSimulation is activated on the delivery.

If the target_source is changed in a Simulation Movement

updateFromSimulation is activated on the Delivery The Delivery may end up with multiple target sources.

updateFromSimulation is constrained to execution after propagateResourceToSimulation.

If the target_start_date is changed in a Simultation Movement

updateFromSimulation is activated on the Delivery The Delivery may end up with multiple target start dates.

If the resource is changed in a Simulation Movement

updateFromSimulation is activated on the Delivery The Delivery may end up with more resource lines. Changes in the simulation are reflected through target quantities and quantities.

If the variation is changed in a Simulation Movement

updateFromSimulation is activated on the Delivery The Delivery may end up with more resource lines. Changes in the simulation are reflected through target quantities and quantities.