odoo/enterprise#81569
Created by Training, Logan Staelens (lost)
Blocked
- Merge method
- Review
-
CI
- legal/cla: Contributor License Agreement check
- ci/runbot: Odoo Test Suite
- ci/upgrade_enterprise: Test upgrades for enterprise master
- ci/style: Optional style check. Ignore it only if strictly necessary.
- ci/security: Required security check. Can only be ignored by security team.
- ci/l10n: (runtime 1s)
- Linked pull requests
- label
- odoo-dev:master-account-return-lost
- head
- 71f82aeeb2de83cc2fd1017619106ea41d2ae53c
| odoo/odoo | odoo/enterprise | odoo/upgrade | odoo/documentation | |
|---|---|---|---|---|
| master | #201020 missing statuses missing r+ | #81569 missing statuses missing r+ | #7517 missing statuses missing r+ | #12914 missing r+ |
[IMP] account_reports, l10n_*: Introduce Accounting Returns
1) The Big Picture
A 'return' is here defined as some accounting operation to be done at some point in time, with a specific deadline. It can typically consists in some report to submit to the government, some tax payment to make, or whatever closing operation to be done.
In Odoo, returns are materialized through account.return objects. Each of them has a specific state, allowing the user to track the current step of the submission process.
Returns are auto-generated: Odoo creates them one year in advance, using account.return.type objects as templates. This way, the user can have a complete visualization of the deadlines to come, for example by displaying them in a calendar view.
Returns also integrate well in multicompany: when several companies need to do the same return together (typically, submitting a report for tax units or branches), a single return object is created : so the information to track is at a single place, and we avoid useless noise. It also better represents real life: it's a single, global operation to do.
The returns are allowed to define checks, through dedicated code in the module. Those checks are automated, and will be run when displaying the returns, notifying the user in case of failure. When a test fails, the user can investigate and fix it, or bypass it if it proves irrelevant. Executed checks are materialized through account.return.check records. Checks are useful to give guidance: in the past, users just had to know what to do and what they could have forgotten or misused ; not anymore.
2) Versatility
Each country needs to implement its own returns. Since cases vary a lot between those (including wihtin the same country), we want to give full flexibility on the flows that are allowed. Therefore, a lot of manual customization can be done on the states of each return, the buttons that are displayed on them, the actions those return, and the objects they create. The framework around those features has for now been kept minimal, and things stay very manual to define them. It is possible we make it evolve in the future, once we have a few more concrete examples to generalize. Outside of the purely technical comfort, the current solution should already be fully flexible, and is intended to stay so.
3) Tax Closing
The former tax closing mechanism has entirely been revamped to fit into returns.
Here are the major differences:
- Closing entries are now posted automatically upon submission of the return. If they need be modified by hand for whatever reason, it is still possible by resetting them to draft.
- The pdf attachment (and XML for Belgium) are not on the closing entry anymore, but directly on the return.
- The carryover external values are created at submission of the return, not when posting the main closing entry anymore. That means resetting the move to draft and reposting it will not recompute the carryover anymore. To do that, a user must reset the return, and re-submit it.
- There is no more "Closing Entry" button on the reports: instead we show a button redirecting to the kanban list of returns when appropriate, for discovery of the feature. The returns are now the only point to pilot the tax closing from.
Note that, in multicompany, multiple closing entries are still created, like before. But as explained in 1), they are now linked to the same return object.
Tax closings have been adapted for every country, so that they still work like they did before. Belgium goes a bit further, as explained in the following point.
4) Multi-VAT simplification
When using foreign VAT fiscal positions, it was possible to define different foreign VAT within the same country, for different regions. This feature had been implemented a long time ago, and we never actually got any indication it was of any use. Back in the day, it was supposed to do what branches do better now. Since keeping its support would have required to complexify quite a lot the new returns mechanism, we make here the choice to remove it entirely. All the other cases of foreign VAT fiscal positions are of course still supported like before.
5) Belgium as a proof of concept (cocorico !)
As it is, this commit adds multiple return types, wizards and checks to Belgium. The idea is that this localization serves as an example on how the new tools we introduce have to be used. Of course, this is only a first version, and things will probably be added and refined in the upcoming months.
6) What's coming after this commit
All other localizations will need to integrate the returns the same way Belgium did. This will be a long process, and will be done in multiple PRs.