[11.0][ADD] account_spread_cost_revenue

[astirpe]

This module allows to spread costs or revenues over custom periods.

[pedrobaeza]

I think this is very similar to the cutoff + accrual modules in https://github.com/OCA/account-closing

[astirpe]

@pedrobaeza I cannot find the spread functionality in there. Not sure those modules provide the same functionality.

[pedrobaeza]

OK, I don't know too much about that, but it sounds familiar to me when I read the description of the other modules, so it was only a note.

[fclementic2c]

Excellent. This feature was clearly missing.

However, this feature cannot be based on account asset since:

• this module is really crap (date of posting are not at the end of the month for instance, no moves sequence, wrong prorata, no report...) - to me it is not possible to use it in prod env.
• You block possibility to install the OCA alternatives for assets
• You may not want all assets menus created by this module.

I am sorry for being so negative but please... not account_asset

[astirpe]

@fclementic2c thanks!

I think you misunderstood the credits part of the readme. Part of the code of this module, in particular the one that generates the lines, is inspired from the standard account_asset module: we have to mention this fact in the credits.

However this module:

• is totally unrelated to the account_assets module
• does not block the installation of the OCA assets module
• does not make use of any menu item (not yet)

Do I misunderstand your comment?

[yung-wang]

The functional idea is the same with account-closing. The main difference that i found, is that the cutoff + accrual modules only creates 1 journal entry (even with multiple months). With the cost spreading module you can create 1 journal entry per period.

cutoff + accrual modules:
Rental Invoice for 6 months. The system will create only 1 journal entry for these 6 months on the cutoff date.

Cost spread:
Rental Invoice for 6 months. The system will create 6 journal entry for these each months with a date in each month (or other period you define).

[pedrobaeza]

So they are basically the same? The maybe it's better to add a new option in the existing modules to allow the spread through months.

[yung-wang]

@pedrobaeza It is not really the same. The closing modules are for finance closing procedure. You decide at the end of the year how you want to register accrual cutoff, more something that an accountant would do.

The spreading module is for the split of the cost and revenue during entering the invoice. This provide the user the ability to spread the amounts to his liking. Also @fclementic2c is missing this feature. So I suggest to keep these 2 separate.

1 for the closing procedure.
1 for the entering invoices.

[pedrobaeza]

OK, but it's a pity that they don't share code as the internals are the same, although functionally speaking they are for different purposes.

[fclementic2c]

I did a test. I have several comments @astirpe :

• We need 2 (not one) spread accounts (in the french accounting for example you use the 4886 for expenses and 4887 for revenues).

• Please add a tooltip to explain that the spread account is a Balance Sheet account - This is important to understand to rational of this module (and this is the error that Odoo did on their "deferral revenue" module - All entries are posted the other way around and confuses accountants - although if you do the math it is correct...)

• Possible improvement: Journal & spread accounts should be defined in a dedicated section under accounting / settings

• I notice a small issue when pressing UNDO spread, the spread account disappear, I had to put it back manually to be able to recompute.

• Accounting issue: On the month of the supplier invoice reception the expenses must move 'accounting-ly' to the spread B/S account : Debit Spread acc. to Credit Expenses for the same amount than the one on the invoice.

Let me give a example: a "1 year offices cleaning contract" from 01/01/2018 to 31/12/2018 - amount 12000 eur

Cost spreading:
January : Debit Expense acc. to Spread B/S acc - 1000 eur
February : Debit Expense acc. to Spread B/S acc - 1000 eur
March : Debit Expense acc. to Spread B/S acc - 1000 eur
April (Invoice received for 12 500 eur) : Debit Spread B/S acc. to Credit Expenses acc. - 12'000 eur - This way you cancel the supplier invoice line entry (Debit Expenses to Credit Payable)
April : Debit Expense acc. to Spread B/S acc - 1000 eur
...etc... until Decembre.

In december (last month of the fy) all spread accounts balance must be = 0.

• Other accounting point: In January you have not received the supplier invoice, it means that you do not know if the supplier invoice will 12000 eur exactly... you must be able to create the cost spread from a dedicated menu and not from the invoices lines + You must be able to indicate an estimated amount.

Frederic

[astirpe]

@fclementic2c thank you very much for trying out this module. Thank you also for the constructive review you made. Indeed the solution you are proposing is the proper one and I'm already working on it. I'll keep you updated with the progress.

[yung-wang]

@fclementic2c About:

On the month of the supplier invoice reception the expenses must move 'accounting-ly' to the spread B/S account : Debit Spread acc. to Credit Expenses for the same amount than the one on the invoice.

In the Netherlands it is common practise to not do the full move of the spread to the cost. We find these kind of journal entries too much and it adds extra noise. I agree that the French ways is also correct, because at the end the balance of the accounts are zero.

So to clarify question
Accounting in France

Vendor invoice:
Expenses 12.000,-
to Credit Payable 12.000,-

Spread cancel entry full amount
Spread B/S 12.000,-
to Expenses 12.000,-

Spreads (12 times in total for each month)
Expenses 1.000,-
to Spread B/S 1.000,-

Accounting in the Netherlands

Vendor invoice:
Spread B/S 12.000,-
to Credit Payable 12.000,-

Spreads (12 times in total for each month)
Expenses 1.000,-
to Spread B/S 1.000,-

So I would propose to make these way of accounting optional.

[luc-demeyer]

For companies already using the account_asset_management module, the account_asset_management_method_number_end modules does the trick, can be configured the french and netherlands way, has reporting and follows the same way of configuring and using it as the financial assets management. The name is confusing though and if the customer only wants to do the cost/revenue spreading than they get too much functionality in their accounting menu.

I think that having a similar usage and way of configuring financial assets and cost/revenue spreading has an advantage for the end users but it is clear to me that the current account_asset_management_method_number_end needs to be renamed (at some point in time) and a bit reworked to make it's purpose more clear (and on top of this there is still the ongoing debate to move the 'method number' into the base account_asset_management module).

[sbidoul]

This looks very interesting. I've not looked in details yet. A couple of quick toughts nevertheless.

Possible improvement: Journal & spread accounts should be defined in a dedicated section under accounting / settings

At first glance, I'd say this module should share the same base configuration as the accrual modules in account-closing: https://github.com/OCA/account-closing/blob/11.0/account_cutoff_accrual_base/models/company.py @astirpe would it make sense to you?

I suggest moving it to the OCA account-closing as the scope is very similar.

@yung-wang Note people actually do revenue/expense spreading using account_cutoff_prepaid: they just do the cutoff + reversal dance once a month, in addition to year end closing. The cutoff module only works after the invoice has been validated, though, while this module allows spreading draft invoices several month before they are received, correct?

This also sounds reminiscent to account_invoice_accrual, which only allows one move to accrue a draft invoice. This gives me the idea account_invoice_accrual could maybe support start/end dates. Anyway, I understand some people prefer having an explicit spreading board.

[astirpe]

@sbidoul

At first glance, I'd say this module should share the same base configuration as the accrual modules in account-closing: https://github.com/OCA/account-closing/blob/11.0/account_cutoff_accrual_base/models/company.py @astirpe would it make sense to you?

Not sure if the accrual accounts and journals are the same as the spread accounts and journals. If that is the case, yes: we should share the same base configuration. I would turn the question to our functional guys... Same discourse for moving the module to OCA/account-closing: no-problem but I would like to have a valid functional reason (not just similarities of few lines of code) for doing that.

The cutoff module only works after the invoice has been validated, though, while this module allows spreading draft invoices several month before they are received, correct?

I'm busy to allow the spreading also while the invoice is not received yet. The module at this moment only allows the spreading when the invoice has been validated. Working on it...

[yung-wang]

@luc-demeyer Using the spreading with assets module is confusing, we want to spread invoices without having assets installed.
I think the account_asset_management_method_number_end should be merged in the standard assets, because in The Netherlands we do depreciation also based on number of periods. But that discussion should be done in the other thread.

@sbidoul I tried the account-closing modules: You cannot create 2 prepaid cut-offs on the same date. Also you need to have an invoice already existing. So for me the closing modules are not useful for the functionality that we want for spreading.

[luc-demeyer]

@yung-wang
I agree that the account_asset_management_method_number_end is somehow a quick and dirty way to do revenue/cost spreading and confusing from a User Interface standpoint. But it works and the usage and configuration is consistent with the way the assets work. When moving to v12 we should analyse if the OCA account close, assets and revenue/cost spread modules can be aligned at least from a User Experience standpoint. In the case of the account_asset_management module a bit code refactoring would be needed to move the common code for assets and revenue/cost spreading to a technical module and have an asset and revenue cost/spread modules inheriting the common logic and covering primarily the UI elements.

Concerning moving the method number to the base module: it will take less time than this discussion but I think that it is important that we first doublecheck the requirement before doing so. I have myself rolled out this module to several Odoo instances in the Netherlands and didn't get the demand for a number based method. If your customer wants 60 monthly depreciations than you can as well teach him to configure an asset profile for monthly depreciations over 5 years. If it's legally allowed in the Netherlands to e.g. depreciate over 'partial' years e.g. 57 monthly depreciations than we need to decide if we want to support this requirement via the base module or a small localisation module.

[sbidoul]

@yung-wang

You cannot create 2 prepaid cut-offs on the same date

Why would you want to? A single cutoff will handle all invoices that have a start/end date.

you need to have an invoice already existing

That is true. You cannot start cutoff from draft invoices. That's why I suggested there might be a use case to have account_invoice_accrual handle start/end dates.

But as I said, I'm perfectly fine with having a second method to do this spreading.

The only thing is that I'm 99% sure that the configuration is the same, that's why I suggested to move it use the same base module for config, and possibly move it to the account-closing repo.

[fclementic2c]

Reply to @yung-wang about :

Accounting in the Netherlands

Vendor invoice:
Spread B/S 12.000,-
to Credit Payable 12.000,-

Spreads (12 times in total for each month)
Expenses 1.000,-
to Spread B/S 1.000,-

I totally agree with you, it is the same in France or here in Switzerland but I was thinking that is will be to 'messy' to implement it to Odoo this way. If you post the extra entry I am suggesting it is maybe a bit of noise but you do not need to change anything to the invoice line creation method.

[fclementic2c]

Not sure if the accrual accounts and journals are the same as the spread accounts and journals. If that is the case, yes: we should share the same base configuration. I would turn the question to our functional guys... Same discourse for moving the module to OCA/account-closing: no-problem but I would like to have a valid functional reason (not just similarities of few lines of code) for doing that.

@sbidoul @pedrobaeza
Accruals/prepayment are cut-off entries -> legal requierement
Account spreading is purely for reporting purposes -> it is more similar to analytic accounting -> not legal -> analysis purposes.

It means that they must be clearly separated in different journals.
In fact, you can do expenses/revenues accruals PLUS do some spreading on the same expenses/revenue. Both entries can be combined (ex in french only sorry: https://www.compta-online.com/compte-4886-comptabiliser-abonnement-des-charges-ao2651-> it means it is clearly different.

This module will not create draft invoices it is pure accounting.

[pedrobaeza]

@fclementic2c thanks for the clarification. I still think they can share technical methods for creating stuff, but it's up to you to decide this as I don't know too much all this stuff.

[fclementic2c]

@pedrobaeza They can surely share some methods but I cannot tell which ones :)

[fclementic2c]

To help you to take this decision, I wrote 2 uses cases we have to handle:

https://docs.google.com/spreadsheets/d/1WBlNdvlajWOw7hvDExDdKw1g4dENU3LttQ5_wTpMDfI/edit#gid=1162062140

Feel free to tell me if I did mistakes (I did it a bit quickly)

[astirpe]

@fclementic2c thank you very much!

I just pushed the latest development made on this module, it is now possible to create spreads even when the invoice is not yet received. I want to continue to work on it, so I set its version to "Alpha".

[dreispt]

/ocabot merge nobump

[OCA-git-bot]

This PR looks fantastic, let's merge it!
Prepared branch 11.0-ocabot-merge-pr-715-by-dreispt-bump-nobump, awaiting test results.

[OCA-git-bot]

Congratulations, your PR was merged at 19cb143. Thanks a lot for contributing to OCA. ❤️