When planning a Manufacturing Order, if an operation takes place in work
center with a different time zone, the computed date may be incorrect
(the start date may be outside the working hours)

To reproduce the error:
(Use demo data. Current timezone: Europe/Brussels)
1. In Settings, enable "Work Orders"
2. Open an existing Work Center
3. Click on "Standard 40 hours/week"
4. Set Timezone to "Asia/Bangkok"
    - Note that all slots are between 8:00-12:00 and 13:00-17:00
5. Create two storable products P_compo and P_finished
6. Create a Bill of Materials BM:
    - Product: P_finished
    - BoM Type: Manufacture this product
    - Components: 1 x P_compo
    - Operations: 3 x Operation with existing work centers
7. Create a Manufacturing Order:
    - Bill of Material: BM
    - Quantity: 100
8. Save, Confirm, Plan

Error: (it depends on the time the test is done) The 'Scheduled Start
Date' of the second operation is incorrect. Adding the time zone
difference gives a time that is outside the work center's timetable
(i.e., outside 8:00-12:00 and 13:00-17:00).

The computations do not consider the time zone of the work center.

OPW-2393330

Forward-Port-Of: odoo/odoo#71310
Forward-Port-Of: odoo/odoo#70841

This legacy package was supposed to be an alias to `odoo.upgrade`.
However, depending on how your import its sub-packages (and in which
order), we were ending with the module being loaded multiple times,
breaking the expectation of a singleton.

```python
In [1]: from odoo.addons.base.maintenance.migrations import util as m1

In [2]: import odoo.addons.base.maintenance.migrations.util as m2

In [3]: m1
Out[3]: <module 'odoo.upgrade.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>

In [4]: m2
Out[4]: <module 'odoo.addons.base.maintenance.migrations.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>

In [5]: from odoo.addons.base.maintenance.migrations import util as m3

In [6]: m3
Out[6]: <module 'odoo.addons.base.maintenance.migrations.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>

In [7]: m2 == m3
Out[7]: True

In [8]: m1 == m3
Out[8]: False

In [9]:
```

Now, with this import hook, we ensure that the modules imported from
`odoo.addons.base.maintenance.migrations` are aliases to ones imported
from `odoo.upgrade`.

```python
In [1]: import odoo.addons.base.maintenance.migrations.util as m2

In [2]: m2.__name__
Out[2]: 'odoo.upgrade.util'
```

Forward-Port-Of: odoo/odoo#71323
Forward-Port-Of: odoo/odoo#69386

German localization for the point of sale application.
Related task ID: 2055957
Community eddition related PR: https://github.com/odoo/odoo/pull/65148 
(Weirdly enough, I could not create this PR as draft)

Following the new regulation of the German government, a Technical Security System (`TSS`) is needed in every PoS. A `TSS` is a device that mainly records every operation of a transaction. It is the central technical component for securing the basic data records against subsequent manipulation. A cloud-based solution was chosen with the help of Fiskaly which is a German company providing the required services in the form of APIs. To be compliant with the regulation, several features have been implemented:

### Configuration
In order for the user to use this localization, his company need to be registered at the financial authorities in the company setting. The following features use the IAP Fiskaly service as a middleware:
  - The registration can be done by clicking on a button (the option will only appear if the company resides in Germany). An `organization` with the required information will then be created at Fiskaly side. This also results in the creation of `credentials` (an API `key` and `secret`) that allows the user's system to use the services provided by Fiskaly and will be stored in the user's system. 
  - Whenever a mandatory field is updated (e.g., street or city), a request is sent to update the `organization` information at Fiskaly side.
  - Requesting a new pair of `credentials` is also possible (in case the current ones got corrupted for example)

After retrieving the `credentials`, the user can now create their `TSS`. To do so, a `client` need to be created at Fiskaly side. This `client` will represent the cash register of the user. It is possible to create more than one `TSS` per `client` but this is not recommended. A one to one mapping will probably reflect the regulation.
- Creating both `client` and `TSS` can be done in the pos_config form. A checkbox will need to be ticked and the form needs to be saved. This will send the required data and the newly created `TSS id` and `client id` will be stored for further use.
- Deleting a pos_config will also disable its corresponding `TSS`.  

### Point of Sale UI
Fiskaly works with a transaction system for the order. A `transaction` is first created with a HTTP request. Afterwards, a second HTTP request with the mandatory information of the order is sent to update and finalize the `transaction`. This is what we call `short transaction`. There are also different types of transaction.
- The basic PoS only works with `transaction` of type `receipt` which simply retrieves the payment information along the taxes. 
  - A `transaction` of type `receipt` is always created and finalized (two requests are sent, one after the other) whenever an order is validated in the payment screen. This happens before the order is sent to the Odoo server.
  - The receipt shows the mandatory data received from the `transaction` finalization response. 
  - A `transaction` can also be canceled if it was first created. For example, if during the validation of an order, the second HTTP request failed due to some unknown error (the first request went through, meaning that a `transaction` was created at Fiskaly side), the system cannot proceed further and complete the validation of the order. The user can cancel the order which will send a HTTP request to Fiskaly in order to cancel said `transaction`. 
  - The unpaid orders are stored in the `localStorage` along their `transaction id` if the `transaction` was created but not finalized. The user should not delete their browser cache, otherwise the unpaid orders will be lost and the `transaction` will be indefinitely open at Fiskaly side. 
  - The unpaid orders are properly loaded from the `localStorage` with their `transaction id`.
  - The `TSS related information` (the ones shown in the receipt) are also sent to the Odoo server and stored. 
  - The reprint feature also shows the `TSS related information` in the receipt.
  - Once the PoS UI loads, the system retrieves the German taxes from an API of Fiskaly. The values cannot be hard-coded since they can change because of the Covid-19 crisis. A VAT check is applied when selecting a product which verifies if the tax value of the selected product matches one of the VAT retrieved from Fiskaly.
- The restaurant PoS with floor works the same way as the basic one. Some additional features were added to make it compliant with the new regulation. Not only it is working with `transaction` of type `receipt`, but it is also using `transaction` of type `order`. This type of `transaction` retrieves the order line information such as its quantity, its name and its price per unit (vat included). Normally, a `long transaction` would be the ideal schema for this kind of PoS but this is not suited with the restaurant module.. A `long transaction` is simply a `transaction` where we need to update it several times before finalizing it. Fortunately, it is possible to only use `short transaction`:
  - A `transaction` of type `order` is created and finalized when there's a difference in the order lines between the PoS UI and the Odoo server. This happens when changing screen from product Screen to the floor Screen. More precisely it happens when the `create_from_ui` method is called. The difference between the order in the UI and the order stored in the database is then computed and sent. Based on the result, a `transaction` is created and finalized.
  - When validating an order, a rpc call is made to the Odoo server to see if there's any difference before it actually validates. It is possible for the order to not be synced yet after the creation/modification of an order because the screen did not change to the floor screen. Based on the response from the server, a `transaction` of type `order` is created and finalized.
  - The `time_start` data added in the receipt is not taken from the `transaction` of type `receipt` when validating the order but from the creation time of the order.
  - When canceling an order, upon calling the `remove_from_ui` method, it will give the order lines of the order stored in the database as differences (the data in the database is more relevant than the one in the UI). Based on the result (if the order was not actually empty), a `transaction` of type `order` is created and finalized followed by a canceled `transaction` of type `receipt`.
  - The price change and price discount of a product also have been taken into account. Since it is already considered as another order lines, it is also considered as such when creating the `transaction` of type `order`.
  - Split billing feature also has been automatically taken into account with the previous features.
  - Bill printing feature does not show the `TSS related information` in the receipt since they are empty.

### DSFinV-K and Cash point closing (closing a session)
When closing a session, all the information regarding the orders of the session needs to be sent to the DSFinV-K API of Fiskaly. This allows to retrieve those information in a standardized data format which has to be provided in the case of an audit:
- When closing a session, a HTTP request is sent to create a `cash point closing` at Fiskaly side with the required data. A lot of data is sent and can be seen in the `pos_session.py` file. Note: if the amount of an order exceeds 200€, the address buyer should be recorded and sent. If the buyer or the address was not recorded from the user, the system will simply send an empty address. Odoo is not responsible for the user's lack of responsibility. 
- An export of the data sent can be created and is `DSFinV-K export`. The export can be created either for a specific PoS or for every PoS. A period of time needs to be specified. The creation of a `DSFinV-K export` will trigger an export at Fiskaly side.
- Once a `DSFinV-K export` have been created, depending on the `state`, a button will be available to refresh its `state`. This will simply send a request to get the state of the export at Fiskaly side.
- Once the export has been completed (`state == 'completed'`), a button will appear allowing to download the export.
  
-----------------

Everything works only for company residing in Germany.
The **vast majority of potential errors** have been taken into account and properly handled.

The localization is not ready yet because the required fiscal API (Fiskaly) is not 100% ready yet and some minor change and verification (there will some unknown variables that will come) will need to be done just in case.
Stuff to do:
- ~~remove the `txLastRevision` in the `Order` js class, it's useless because we use short transaction~~
-  Add the fiskaly service IAP endpoint for production
- disable TSS upon archiving PoS ?
- ~~handle duplicate (should create new tss for the duplicated pos)~~

Stuff to be angry with the alpha APIs:
- When creating a `cash point closing` with only one order, most of the time (95%), the `cash point closing` will not be properly created at Fiskaly side because there will be an error with the code `42601` which is a `SYNTAX ERROR` in a PostgreSQL...
- With their management API, when deleting an organization, for some unknown reason : INTERNAL ERROR :dagger:

Forward-Port-Of: odoo/enterprise#15996

Following the validation of the report line domains with
odoo/enterprise#18228

`l10n_mx_reports/data/account_financial_report_data.xml` no longer
loads correctly because the domain is invalid for account.move.line.

```
  File "/home/odoo/src/enterprise/12.0/account_reports/models/account_financial_report.py", line 455, in _validate_domain
    raise ValidationError(error_format % (record.name, str(e)))
odoo.tools.convert.ParseError: "Error while validating the domain of line 101 Caja:
Invalid field 'tag_ids' in leaf "<osv.ExtendedLeaf: ('tag_ids', 'in', [5]) on account_move_line (ctx: )>"
None" while parsing /home/odoo/src/enterprise/12.0/l10n_mx_reports/data/account_financial_report_data.xml:55, near
<record id="mx_afrl_101" model="account.financial.html.report.line">
            <field name="name">101 Caja</field>
            <field name="code">MX_COA_101</field>
            <field name="sequence" eval="0"/>
            <field name="level" eval="2"/>
            <field name="figure_type">no_unit</field>
            <field name="parent_id" ref="mx_afrl_1"/>
            <field name="domain" eval="[('tag_ids', 'in', [ref('l10n_mx.account_tag_101_01'),])]"/>
        </record>
```

The reason for this lies in the fact l10n_mx_reports uses financial report lines in an uproper way to only store the domains for account.account records to use in a custom report: https://github.com/odoo/enterprise/blob/12.0/l10n_mx_reports/models/coa.py#L59. We fix this by overriding the constraint in order to adapt the check made for those lines.


upg-10593

Forward-Port-Of: odoo/enterprise#18383