For now, reporting are based on a date (ex: Balance Sheet) or on fiscal year/period (ex: Income Statement).
This is mainly linked to the context options available in Move.query_get.
Some users may want to have smaller range than the periods (defined for tax reporting), so the logical new layer would be a range of dates.
Proposal
We could add start/end dates as context options to Move.query_get and add such field to the context of reports that are already based on fiscal year/period.
This date range will come in addition to the fiscal year and period but they should be limited by the values of those.
That is, to only consider ranges (between periods or dates).
The fiscal year is, after all, nothing more than the range of all the periods it contains, or the date range.
It is also mighty important to be able to filter on the journals.
This would greatly simplify reporting for interim reports or any other particular need.
Consider a fiscal year (calendar year) in tryton with 12 standard periods and a closing period on the last day of the year. (e.g. Fiscal year => 2016; periods => {01/2016 … 12/2016, 99/2016})
Specifying Fiscal year = 2016 obviously means by default all periods (from 01/2016 to 99/2016) or the fiscal years date range from 01/01/16 to 31/12/16
To get a meaningful balance after having balanced non-deferrals, then one currently needs to specify period range 01/2016 … 12/2016. It won’t currently work with date range 01/01/2016 … 31/12/2016 because of the overlapping date for the closing period (31/12/2016 … 31/12/2016).
The correct approach would be to simply filter out the closing period journal movements (e.g. ‘CLO’), then either the period or date range (complete) should work just fine.
Also, for auxiliary accounts, one should be able to filter (and group) by party as well.
Finally, for interim reporting, there may be a situation journal where in some adjustments are made in order to prepare, for example, a quarterly or half-year report.
I believe tryton needs some particular extra work here in order to be useful, such as explicitly preventing posting moves in such a situation journal as to not interfere with the production accounting data, and probably avoid as well including such moves by default (without explicitly including the situation journal) in reports.
I am agree with the proposal to add start/end date inside query_get. With this new filters users will be able to perform reports on specific range of dates which does not necessarily match with periods or fiscal years.