@@ -134,12 +134,12 @@ SELECT SUM(quantity) from stock where Node='Carol' and Date <= Thursday
## Movements properties
In our candy example, we abstracted many of properties that are needed on movements to represent the complexity of real business cases.
A more realistic example could be ``20 kilograms of *sand* delivered from supplier to warehouse where the unit price is 10€``.
A more realistic example could be ``20 kilograms of *sand* delivered from supplier to warehouse where the unit price is 10¬``.
In that example movement, supplier organisation is the *source*, warehouse is the *destination*. The *resource* is sand, *quantity* is 20, the *quantity unit* is Kilogram, the *price* (per unit) is 10 and the *price currency* is the Euro currency. Quantity and Price properties are set on movements and we can calculate the *total price* by multiplying the quantity by the price. In that case, total price is $20*10 = 200$.
There are movements of different types that are stored in different modules, for example there are order, delivery or invoices movements. We also separate sales, purchase and internal movements. All movements have a *portal_type* property that can be for example `Purchase Order Line` or `Sale Order Line`. Portal Type comes from Zope CMF and is used to configure technical aspects such as the available view and the applicable security rules, so there is an higher level to define what is the kind of movement; this is the *use* category.
Movements have a *simulation_state* which is controlled by a simulation workflow. Movements are usually part of a *delivery* on which users with the proper accreditation can pass workflow transitions to change the state. For example, one sales agent can "confirm" a sales order, that will change the simulation state of all the movements from planned to confirmed. Typically, simulation states are used for different level of certainty and have different level of planning.
Movements have a *start_date* and a *stop_date* properties whose types are Zope DateTime instances.
Even if in our example the total price is 200€, the "value" of this movement can be different for the supplier and for the warehouse. The supplier may want to account that the value of these 10Kg of Sand was, let's say, 110€. The *source_total_asset_price* property of a movement holds the value of this movement in the source's inventory and symetrically, the *destination_total_asset_price* the value in destination's inventory. Source asset price is always in the source's accounting currency and destination asset price always in destination's accounting currency.
Even if in our example the total price is 200¬, the "value" of this movement can be different for the supplier and for the warehouse. The supplier may want to account that the value of these 10Kg of Sand was, let's say, 110¬. The *source_total_asset_price* property of a movement holds the value of this movement in the source's inventory and symetrically, the *destination_total_asset_price* the value in destination's inventory. Source asset price is always in the source's accounting currency and destination asset price always in destination's accounting currency.
Movements also have an *efficiency* property to note that a percentage of the movements quantity can be lost during the movement. For example, a movement with quantity 10 and efficiency of 95% would decrease the source's inventory by 10 and increase the inventory of the destination by 9.5. This is what we call source *inventoriated quantity* and *destination inventoriated quantity*.
