Reporting based on date range

(Cédric Krier) #1


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.


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.


(Richard PALO) #2

IMHO, this is a good idea.

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.


(Cédric Krier) #3

I do not understand this sentence.

Please could you be more specific about use cases which may require such filtering so that the relevance could be correctly evaluated.

(Richard PALO) #4

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’m mentioning it now for completeness.

(Cédric Krier) #5

I do not understand this comment. It seems that it is just general thoughts, not linked to the proposal.

(Cédric Krier) #6

This works perfectly with periods.

Please provide the name of the reports that requires such feature.

This is already supported by closing the journal for the wanted period.

I do not know what kind of operation are referring, but for me, it looks like the use of situation period.

(Diego Abad) #7

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.

(Cédric Krier) #8

FYI, the implementation is ready to be tested:

(Cédric Krier) #9