group items in Complete List of supported parameters

README.md

@@ -238,50 +238,77 @@ for brain in getInventoryList(node_uid=(N1.getUid(), N2.getUid()),
 ## getMovementHistoryList
 ## Complete List of supported parameters
 
+### date
 - from_date: only take into account rows with date >= *from_date*
 - to_date: only take into account rows with date < *to_date*
 - at_date: only take into account rows with date <= *at_date*
-- node: only take into account rows which *node_uid* is equivalent to *node*
+- mirror_date: XXX
+
+### perimeter definition
+
+#### specifing node
+- node: only take into account rows which ode_uid* is equivalent to *node*
 - payment: only take into account rows which *payment_uid* is equivalent to *payment*
 - section: only take into account rows which *section_uid* is equivalent to *section*
 - mirror_section: only take into account rows which *mirror_section_uid* is equivalent to *mirror_section*
+
+#### specifying node category
 - resource_category: only take into account rows where *resource_uid* is member of *resource_category*
 - node_category: only take into account rows which *node_uid* is member of *section_category*
 - payment_category: only take into account rows which *payment_uid* is a member of *section_category*
 - section_category: only take into account rows which *section_uid* is member of *section_category*
 - mirror_section_category: only take into account rows which *mirror_section_uid* is member of *mirror_section_category*
+XXX note on performance, instead of a for example a node_category query, if the number of nodes is small enough, it is usually better to do a first catalog search to find all the nodes matching node_category and pass them as node_uid. The same applies for all `_category` parameters, node was an example here.
+
+#### filter
+( XXX is this really implented ?)
 - node_filter: only take into account rows which *node_uid* matches *node_filter*
 - payment_filter: only take into account rows which *payment_uid* matches *payment_filter*
 - section_filter: only take into account rows which *section_uid* matches *section_filter*
 - mirror_section_filter: only take into account rows which *mirror_section_uid* matches *mirror_section_filter*
+
+#### omit
+Allows to only consider incoming or outgoing movements.
+- omit_input: do not take into account movement with *quantity > 0*
+- omit_output: do not take into account movement with *quantity < 0*
+- omit_asset_increase: do not take into account movement with *asset_price > 0*
+- omit_asset_decrease: do not take into account movement with *asset_price < 0*
+
+#### variation
 - variation_text:  only take into account rows with specified *variation_text*. It is implemented in a very far from perfect way and had poor performance. **(XXX: what is this?)**
 - sub_variation_text: ???
 - variation_category: only take into account rows with matching *variation* or where its *variation* is a member of this list
+- ignore_variation: do not take into account variation in inventory calculation **(XXX: what is this?)**
+
+#### movement states
 - simulation_state: only take into account rows with the specified *simulation_state*
 - transit_simulation_state: only take into account rows which states are transit states 
 - omit_transit: do not evaluate *transit_simulation_state*
 - input_simulation_state: only take into account rows with specified *simulation_state* and *quantity > 0* **(XXX: why do we have duplicated parameters? this can be achieved by using two existing parameters, for i.e., this can be reproduced by using *omit_output* and *simulation_state*)**
 - output_simulation_state: only take into account rows with specified *simulation_state* and *quantity < 0* **(XXX: same as line above)**
-- ignore_variation: do not take into account variation in inventory calculation **(XXX: what is this?)**
-- standardise: not implemented **(XXX: if not implemented, why documented?)**
 - omit_simulation: do not take into account simulation movements
-- only_accountable: only take into account accountable movements. Default is *True*
-- omit_input: do not take into account movement with *quantity > 0*
-- omit_output: do not take into account movement with *quantity < 0*
-- omit_asset_increase: do not take into account movement with *asset_price > 0*
-- omit_asset_decrease: do not take into account movement with *asset_price < 0*
+
+#### grouping
 - group_by_variation: group results by variataion
 - group_by_node: group results by node
 - group_by_mirror: group results by mirror
 - group_by_sub_variation: group results by sub variation
 - group_by_movement: group results by movement
+- group_by: a list of columns supported by catalog API.
+
+Grouping parameters are for getInventoryList, but they also can be applied to getMovementHistoryList.
+
+#### misc
+- only_accountable: only take into account accountable movements. Default is *True*
 - precision: the precision used to round quantities and prices
 - metric_type: convert results to an specific *metric_type*
 - quantity_unit: display results using this specific unit
 - transformed_resource: the resource or list of resource that can be produced using the resulting movement's resource as an input. *relative_resource_url* for each line will point to the transformed resource, while the stock will be expressed in number of the respective transformed resources **(XXX: what does this actually mean?)**
 - transformed_variation_text: to be used with *transformed_resource* to refine the transformation selection only to those using variated resources as input
 
+
 # Inventory "documents"
+
 Whereas we calculate inventory by summing all the movements to date, there may be differences between the theorical stock in the database and the real stock on the warehouse floor. It is common business practice to make so called "inventory" (XXX check in dictionary) where people go on the floor and count how many items of each resource are physically present in each stock locations.
 After this, they can input the actual values in an `Inventory` document.