Based on the budget cell coordinates, and sometimes the categories defined on the budget line, we must be able to use inventory API to calculate the consumed or the engaged budget.
Budget Variations are used to define the possible variations, so it's natural to configure on each budget variation how this variation will be used in inventory query. The variation can be used as node, section, mirror_node, function, project, or node_category, section_category or any other axis supported by inventory API. To implement this, we have introduced a new category named inventory_axis. Each Budget Variation can be associated to an inventory axis.
In the example above, we have one Category Budget Variation on group category, which is used as section_category parameter in the inventory query, and one Node Budget Variation on source category, which is used as node parameter in the inventory query. By this process, coordinates of a given cell are translated into an inventory API query parameters. A budget defines a range of dates, those dates are also used as from_date / to_date to calculate budget consumptions.
Budget consumption uses getCurrentInventory, because the consumption is what actually happened. Budget engagement uses different simulation states, for engagements we also want to include what has been planned. For example, in the case of a budget on accounting lines, confirmed orders and invoices are for engaged budget, and stopped/delivered accounting transactions are for consumed budget. In this example, simulation movements at invoice transaction rule level that comes from this order will be selected to calculate engaged budget.
Note that we do not use getFutureInventory for engaged budgets, because of SimulationMovement.getSimulationState: inside the simulation tree, deep movements are simply planned. Instead, we do a query based on the simulation state of the explanation of the movement.