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.

task-4627315

In this commit, we added the envelope feature on `sign.template` by allowing handling multiple attachments in the same template. The changes description and coding choices explanations are described below. 

**SignDocument addition**
For achieving this, we created a new class called `sign.document` and made `sign.template` point to multiple of them. This class stores an attachment and holds the order information in the template, as well points to its `sign.item` records, previously done in `sign.template`. All the rendering code got moved from `sign.template` to `sign.document` since it now stores the attachment, making the `sign.template` code a lot cleaner and easying the adaptation of the JavaScript rendering as well.


**SignCompletedDocument addition**
Before this PR, the storage for the completed document in the `sign.request` was just a single Binary field, and its functions were defined at `sign.template`. In this PR, we added a new model `sign.completed.document` for holding it as moving the document geration over there. This made us keep the simplicity of working with the Binary field (instead of `ir.attachment` directly), we were able to move a function over there making it more maintainable and allowing future improvements such as moving the certificates logic.


task-4555838

Co-authored-by: Gabriel Felix <gdpf@odoo.com>
Co-authored-by: Ahmad Elmaghraby <alah@odoo.com>
Co-authored by: Abdelrahman Fawzy <abdh@odoo.com>