We are usually interested in knowing the stock level at a certain point of time. This is rather easy, because we usually record the point in time when the movement occured.
It may happen that the movement itself takes some time and that there is a difference between the time when resource beeing leaves the source and the time when it arrives at destination.
It may happen that the movement itself takes some time and that there is a difference between the time when resource beeing leaves the source and the time when it arrives at destination.
To support this, movements have two properties:
...
...
@@ -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*.
XXX Difference from Amount and Movement.
...
...
@@ -194,12 +194,12 @@ XXX explain that the idea is to pass parameter to represent a "perimeter" to con
XXX more ?
This method does not check that the provided parameters leads to results that make sense in the real world. With this method, one can request the sum of kilograms of carots + litters of gasoline.
## getInventoryAssetPrice
`getInventoryAssetPrice` returns the total "values" XXX of the movements.
`getInventoryAssetPrice` returns the total "values" XXX of the movements.
## getInventoryList
`getInventoryList` can query in only one call the inventories of multiple nodes. The aggregation parameters has to be specified. For example, in the case of warehouse inventories, we want to pass `group_by_node=True` and `group_by_resource=True` to get the inventory for each node and resource.
Using one `getInventoryList` is usually much more efficient than doing multiple `getInventory`/`getInventoryAssetPrice` calls.
Using one `getInventoryList` is usually much more efficient than doing multiple `getInventory`/`getInventoryAssetPrice` calls.
For example, this code:
```python
print"N1's inventory of R1 is {inventory}, value is {value}".format(
