[17][ADD] account_analytic_report: New module account_analytic_report

[BernatObrador]

New module account_analytic_report

Using this module is straightforward. Follow these steps:

• Navigate to the Report:
  Go to Invoicing -> Reporting -> Analytic Trial Balance.

• Customize the Report with Filters:
  Adjust the report using the available options:

  • Group by Analytic Account:
    Groups the results by analytic accounts instead of financial accounts.

  • Show Hierarchy and Limit Hierarchy Level:
    Displays the amounts split by the hierarchy levels of financial accounts.

  • Filter Accounts:
    When used independently (without grouping by analytic accounts or showing hierarchy), the results will be split by both financial accounts.
    Example: Filtering by accounts Test 1 and Test 2:

            | Initial Balance | Test 1   | Test 2   | Ending Balance
    400000  |        0        | $3600    | $2400    |     $6000
    

  • Show Months (Excel export only):
    Enabled when filtering accounts without grouping by analytic accounts or showing hierarchy. It generates a separate sheet in the Excel file for each filtered account, detailing the amounts by month within the selected date range.

cc https://github.com/APSL 162352

@miquelalzanillas @lbarry-apsl @mpascuall @peluko00 @javierobcn @ppyczko please review

[BernatObrador]

@pedrobaeza Does this PR need to be reviewed again?

[peluko00]

LGTM, tested in runboat and code review

[pedrobaeza]

Depending on account_financial_report is a very heavy one. Can you light up a bit this?

[BernatObrador]

I'm using some of the trial balance bases from this module as a base. Would it be better to just copy the necessary files from account_financial_report?

[pedrobaeza]

It depends on how much you are reusing and the need for that. Can you specify?

[BernatObrador]

I'm utilizing all the abstract classes provided by the account_financial_report module for trial balances. These classes include QWeb styles and templates, Excel export functionality with styles, PDF export features and some basics for the report. Specifically, I'm inheriting the following classes: report.account_financial_report.abstract_report_xlsx, report.account_financial_report.abstract_report, and account_financial_report_abstract_wizard."

[pedrobaeza]

Seeing the amount of code you need here, not to call super, etc, it seems you are just replacing the existing logic with your own, so I think to not depend on them isn't too much. Can you maybe do a PoC to see?

[BernatObrador]

I believe this could result in duplicated code between this module and account_financial_report. Do you think this is a viable approach? The logic for Excel generation and report styling is already provided by account_financial_report.

One alternative could be renaming this module to something like account_financial_report_analytic or account_financial_report_extension_analytic, to better reflect its relationship with the original module.

[pedrobaeza]

I still think they should be independent. You may want this feature without requiring the other. I think the coupling level is very low. Not all the declared styles in account_financial_report are used here.

[BernatObrador]

@pedrobaeza, I just completed the PoC. Could you take a look and let me know your thoughts?

[pedrobaeza]

In general seems good, although I think there's still a lot of abstraction that can be removed and be done "concrete", but well, I know it's not easy to unmangle all that code.

Anyway, the main doubt is: what is this report adding as value compared with the trial balance grouped by analytic account?

[pedrobaeza]

This seems too much logic for just a report, and a bit disconnected from analytic reporting goal.

[BernatObrador]

@pedrobaeza This report works directly with analytic lines, unlike account_financial_report.
It offers features that the trial balance report lacks:

• The ability to split balances by analytic accounts within the same line.
• Group by only by the analytic accounts
• A more advanced Excel export, allowing you to break down data by the selected range of months for greater accuracy and detail.
• Totals for each account type are included.
• It supports displaying hierarchy, which is not possible in the trial balance report.

[pedrobaeza]

OK, I think all of that reasons should go to the manifest. Then I don't understand the account.group stuff.

[mpascuall]

Without taking into account what @pedrobaeza is asking for, LGTM tested in runboat and code review

[BernatObrador]

@pedrobaeza All the account,group stuff, is needed to show hierarchy property at the report.

Can the reasons for the module be included in the summary? The description field in the manifest is now deprecated.

[pedrobaeza]

That's a mix of concepts IMO. Account group hierarchy is for general accounting, not for analytic reporting.

[BernatObrador]

Not necessarily. In the analytic lines, you have financial accounts, which means you can display a hierarchy based on those accounts. At the very least, you can group by financial account or analytic account. When grouping by financial account, the hierarchy can be shown as well.

[pedrobaeza]

But don't do that on the report. You already have the trial ledger in AFR. As said, I think this is a mix of things.

[BernatObrador]

Hi @pedrobaeza ,

I understand your concern about mixing concepts, but in this case, the hierarchy is a natural property of the data. Each analytic line has an associated financial account, which means that when grouping by financial account, the hierarchy can be displayed as well.

This report is not trying to replace the trial ledger in AFR. The key difference is that AFR focuses on pure financial accounting, whereas this report is based on analytic accounting. The hierarchy here is not just a reflection of financial accounting but a way to structure analytic data that is already linked to financial accounts.

A real use case for this is a company wanting to analyze analytic costs grouped by financial account in a structured way. This allows them to visualize which accounts generate the most costs at both a consolidated and detailed level.

[pedrobaeza]

Well, I still think the same, but I'm not going to block this, as I don't want to discourage you this contribution.

[BernatObrador]

@pedrobaeza Thanks a lot for your time and advice! So it's ready to be merged?

[pedrobaeza]

Well, as I refrain due to my divergences with the approach, other PSC should do it.