Ready to add: improvement of yearly financial stats table

[caos30]

@eldy i made an slight change on the file /htdocs/compta/facture/stats/index.php to improve the yearly statistics on Financial main menu section of Dolibarr.

I made a screenshot of the BEFORE vs the AFTER:

I worked over the Dolibarr 10.0.6 version, but i suppose that it's the same for 11.0.x This is the ZIP file containing the changes: 2020-02-28_financial_stats.zip

Briefly, the improvements

add new columns:

• number of invoices /month
• total amount invoiced /month

modified the DIFF (%) columns:

• These 2 columns let us to modify the 2 columns DIFF showing the percentage of increment regarding the last year: instead of use the values passed in the array of data, i use the monthly averages of those new columns to calculate the increment respect the previous year.
• This is specially interesting (needed?) when comparing the current year with the previous one. Because the current year always is not-completed, so it's usual to see RED VALUES respecting the previous year, although the reality be an increase of results if we compare the month average!
• This modification only affect the calculation for the current year. For the other years on the table, there is no difference between compare the total of the year or the monthly average.

To do:

• Apply something like this to the FIRST year. Because for the first year we also probably don't have 12 months of invoices. So the comparison with the next year is also really biased.

If you need to me to do something else please tell me. I know that usually is recommended to do a PULL REQUEST, but i think that for a so minor change is faster for me and your do it so. At least me, i don't have very clear which branch exactly to add the change... you know.

Cheers, Sergi

[atm-maxime]

Hi. Thanks for joining the community! When you do a new feature like this one, you must do it in the develop branch and make a pull request so we can integrate your changes. This is the faster and easier way. Only bugfix are allowed in previous branches.

Now regarding this, adding the average column why not, but modifying the % column seems wrong to me. I think it would be better to compare same months as previous year.

[caos30]

Thanks for your kindly answer @atm-maxime ! I didn't know that i could do this: make a pull request for a new feature. I will try it tomorrow :-)

Said this, i understand your comment about the % calculation. Sincerely, i had the same doubt. But think about it: whatever you average or comparison you do will have different consequences, obviously. I means, that some indexes or parameters calculated in a way or in another have different benefits and limitations.

I know that the markets usually have an important SEASONAL behaviour. In this sense, i agree with your of the interest of compare the 2 first months of this year with the 2 first of the last year. Buuuut, it would be -maybe- more interesting compare it with the last 2 months of the last year. It would have more sense if the seasonal influence is not so heavy, but it's more important a progressive growth of the activity and success of your business. In fact, Google Analytics do this type of comparison: the current period of time with the previous one.

So, i try to say that it's impossible to put our trust in a unique formula or criteria for comparison, and it probably would be more useful in some cases one or another.

Said this, i thought in a third kind of comparison which is more loyal to this statistical itself: compare the results of one year with the previous years. In this sense, the current criteria applied in Dolibarr need to be FIXED asap! I means: it calculates the % of the number of invoices in the current year (although we're still on February !!!) with the total number of the invoices of the whole previous year!?

I probably were choose your approach (compare jan-feb'2020 with Jan-Feb'2019) but it has several practical problems:

• For do this you would need the totals for each month, but this file only receives the totals by year... so i think that to add a column "average number of invoices / month" is enough smart and useful and easy and practical. Enough. And then this column does has more sense to compare one year with another ;-) It only would be necessary to improve the calculation for the oldest year of that table (the first one), because we probably only have invoices records of the "last" months of the first year. Sincerely, i didn't put my hand on this issue because it would require more information from database, at least to know the date of the oldest invoice.

• Another problem, in the same way is that maybe the previous year (now 2019) our first invoice was in July... so How would we must compare 2019 with 2020 in this table? Do you understand me.

• There is another reason -more theoretical-: maybe the last year happened something strange on some months or maybe we really don't have a very seasonal rhythm... so, it would give us a not very good information comparing Jan-Feb'2020 with Jan-Feb'2019.

• Another mathematical reason: an average of "more entities" are a BETTER and more reliable average. So, in this sense, i think it's good to compare the average of the months of current year -although they are only 2) with the average of the 12 months of the previous year, which it really is a GOOD monthly average of our level of "finances", don't you think so?

Please, don't hesitate to continue this discussion. I really found it interesting. But let me insist that my approach is not only good enough but in a certain sense even convenient.

Cheers!

[caos30]

Reviewing my previous comment, i realise about this: that statistical YEARLY table must contain indexes (columns/parameters) calculated/defined RELATIVE TO THE YEAR. In other words: we're trying to compare years in this table. So, for this reason we compare -for example- the "number of invoices" of each year.

This parameter (number invoices in a year) has many sense if you compare 2 completed years. The question here is that in the current table on Dolibarr the first row at top, corresponding to the current year HAS NO SENSE to be compared with the others, at least with the current columns.

For this reason we need to add a column with an index that don't depend on the portion of the year elapsed. In this sense i found that -let me insist- the index "average number of invoices per month" is an interesting value to be considered when comparing two years, it returns a reliable "measure" of the year financial progress EVEN if we have truncated one of the years (the first and the last years are usually truncated).

My point is that i don't want to compare the first trimester of 2020 with the first trimester of 2019. I want to compare (as close as possible) the finance of "one year" with the finance of "another year". So, a monthly average seems quite good for me.

Even more: when you compare 2 completed years, the difference (in percentage) between one year of another RETURNS EXACTLY THE SAME VALUE if you compare their "total number of invoices" or their "average of total number of invoices per month". So, uhmmm, i think that my proposal is a quite sharp improvement of the % column being used currently on Dolibarr... which is obviously incorrect.

In other words: with my improvement it only will be improved the % comparing the current year with the previous year not affecting the comparison made until now for the other completed years ;-)

It sounds perfect for me. I means: preserve the current meaning of that % column, but fix the weird result for the top row (current year compared with previous year).

Sorry again for my enthusiasm. Please i would like to hear your (or another people) opinion.

[github-actions[bot]]

This issue is stale because it has been open 1 year with no activity. If this is a bug, please comment to confirm it is still present on latest stable version. if this is a feature request, please comment to notify the request is still relevant and not yet covered by latest stable version. This issue may be closed automatically by stale bot in 10 days (you should still be able to re-open it if required).