**[IMP] l10n_it_edi: Tax exemption kind N7 description**

New specs from October 1st 2022:
https://www.doxee.com/it/blog/fatturazione-elettronica/nuove-specifiche-tecniche-per-la-fattura-elettronica-2022-in-vigore-dal-1-ottobre/

The description of Tax Exemption kind N7 is changed to: "IVA assolta in altro stato UE (prestazione di servizi di telecomunicazioni, tele-radiodiffusione ed elettronici ex art. 7-octies, comma 1 lett. a, b, art. 74-sexies DPR 633/72)"

Courtesy of Tony Mascii

**[FIX] l10n_it_edi: San Marino self-invoice from paper**

San Marino is a very small country completely enclosed in Italy. That country has special agreements with Italian as far as e-invoicing is concerned. When a paper invoice is received from San Marino, any Italian company has the responsability to submit that invoice integrated with Italian tax information to the Tax Agency, indicating in the e-invoice filling the Document Type field with the special value 'TD28'.

**[IMP] l10n_it: Round globally by default in Italian CoA**

The Italian Tax Agency (and therefore any business in Italy) makes it mandatory to compute roundings based on a Round Globally policy. Invoices not rounded globally are refused by Italian EDI.

**[IMP] l10n_it, l10n_it_edi, l10n_it_stock_ddt: Deferred invoice**

Context:
The Italian State allows making one invoice per month to recurrent clients buying goods several times a month.
This process is called "Deferred invoice" (Fattura differita) in contrast to Direct invoice (Fattura immediata).

To enable this, the vendor must issue one Transport Document per client delivery. The Document is attached to the goods themselves. Many Transport Documents (DDTs) delivered can then be invoiced together in a single invoice up to the 15th day of the following month.

This task allows the Italian EDI to correctly communicate the Deferred invoices data to the Tax Authority

An export test has been added.

Official FAQ (n.21) - https://www.agenziaentrate.gov.it/portale/documents/20143/287582/15+Tutte+le+faq+%28aggiornate+al+11+maggio+2021%29+.pdf/2db944b9-22c3-fa80-7c14-dfa0bcbbd65e
Reference task link: https://www.odoo.com/web#model=project.task&id=1914640

Forward-Port-Of: odoo/odoo#106797

# Current behaviour
Project Update doesn't take into consideration the `analytic_distribution` percentage of the analytic_account on the line of the purchase orders.

# Expected behaviour
Account correctly for the % of the analytic account for the project, just like in the Accounting app.

# Steps to reproduce
- Install Accounting, Sales, Purchase, Timesheet, Inventory, Project
- Activate "Analytic accounts" in Settings
- Create a product service which is creating a project at sales
- Create a new SO, add the service, confirm the SO and invoice
- Create a new PO, add some random product, on that same line add 2 analytic account, 50% of the SO project we just created, and 50% from any other.
- Confirm the PO
- Go to the SO's project update section, observe the cost is 100% of the line cost, not 50%

# Reason for the problem
`analytic_distribution` ratios are not taken into account when calculation the costs of the project.

# Fix
Get the ratio of the `analytic_distribution` and multiply by it when processing the costs

# Affected versions
- 16.0
- master
---
opw-3079537

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#107422

This module implements communication with the fiscal device for submitting invoices to the KRA (Kenya Revenue Authority). The device supported in this module is the Tremol G03.

-- COMMUNICATION FLOW SUMMARY --
1. "Send Invoice To Device" on account move is clicked
2. l10n_ke_action_cu_post triggers a client action, with serialised invoice data. (more details below)
3. The client action uses the 'post_send' function defined in javascript to forward the request to the /hw_proxy/l10n_ke_cu_send endpoint on the proxy server (more details below)
4. The proxy server wraps the serialised data with the appropriate bytes (for instance, a couple of a checksum bytes), and sends them to the device through serial communication (more details below)
5. The data returned from the fiscal device is communicated back in the request. The client action 'post_send' then triggers the 'l10n_ke_cu_response' with an rpc call, with the aforementioned data from the fiscal device

(more details)
2. The module l10n_ke_edi_tremol inherits from the account_move model in order to provide methods for serialising the data of the account_move and sending it to the proxy server. Fields have been added to the product template to define the HS Code and HS Name (data which is required by the KRA in some circumstances). A field has also been added to the company defining the address of the proxy server. The fields added on the account move are populated by the data returned by the fiscal device, this includes the device serial number, the invoice number on the device, the URL of the invoice on the KRA web portal, and the date/time the invoice was signed.

3. Communication between the client database and the proxy server is defined using a client action defined in
l10n_ke_edi_tremol/static/src/js/send_invoice.js. This allows users who aren't on-premise to communicate with the device, provided the proxy is accessible on the network that the user is on.

4. The proxy server is an intermediary server that should be connected to the tremol G03, and running the IOT drivers from hw_drivers. The driver that supports communication between the proxy server and the fiscal device has been defined in this commit inside of hw_drivers/iot_handlers/drivers//L10nKeEDISerialDriver.py. The proxy server can be run on the IOT box, or on odoo community by running:
./odoo-bin addons-path=.... -d dbname --load hw_drivers --proxy-mode

** all messages are encoded/decoded with cp1251, as defined in the protocol. The company vat code is sent along with the request to compare that sent with that of the device. The 'serial_number' of the device is always returned along with the request, since it is required for the invoice details, and it is retrieved as part of the query to find the registered VAT code on the device.

--- DATA and VIEWS ---
product_view:
adds HS Name, and HS Code on the product product and product template form views.

report_invoice:
adds to the invoice qweb template such that a section including the fiscal device / KRA details is included at the bottom of the invoice when the invoice is rendered as a pdf.

res_config_settings_view:
adds makes the proxy address field editable from the config settings.

account_move_view:
add a tab for the tremol device details and the qr code on the account move form view. The KRA invoice number is also added as an optional field on the account move tree view, and the invoice search view is inherited to make this field searchable too.

(l10n_ke) account_tax_report_data, account_tax_template_data: The tax report is defined for Kenya, and tax tags that link to the lines on this tax report are defined on the existing taxes. This allows the classification of the tax, between zero-rated and exempt, during the serialisation.

task-id: 2950308

Forward-Port-Of: odoo/odoo#106653

This commit fixes two things:

- The owl compatibility layer adds an `on` and `off` method on owl's
EventBus so that it can keep being used as it used to in owl 1. To do
this, it needs to keep track of the the callbacks that are attached to
it and by whom. To do this it keeps a Map where the "owners" are keys.
When calling `off` to remove event listeners, we remove the callbacks
but did not remove the owner from the Map, causing the EventBus to
always hold a strong reference to any object that was given as the owner
to the `on` method, preventing the item from being garbage collected.
Objects that do this are typically components, and components hold a
reference to their owl application that contains the entire tree of
components. This was particularly problematic in tests where components
are created and destroyed at a rapid pace.

- The mock websocket creates a MessageChannel so that it can mock the
server side of the websocket, but it never closes that MessageChannel's
MessagePorts, which can cause garbage collection to be slow to happen
[1] (in practice it looks like these are basically never garbage
collected unless closed). This commit registers a cleanup to close the
message ports after the execution of the current test.

[1]: https://html.spec.whatwg.org/dev/web-messaging.html#ports-and-garbage-collection

Forward-Port-Of: odoo/odoo#108184

# Description of the issue/feature this PR addresses:

Bug with the first print of a PDF with wkhtmltopdf  and permanently crash with kwkhtmltopdf https://github.com/acsone/kwkhtmltopdf

# Current behavior before PR:

When printing a pdf on a new database, the css in the header is missing

You can see it in the log of odoo, that the css is missing

```
werkzeug:  "GET /web/assets/200-c71dbab/web.report_assets_pdf.min.css HTTP/1.1 404 - 2 0.002 0.006
WARNING odoo odoo.addons.base.models.ir_actions_report: wkhtmltopdf: b'Exit with code 1 due to network error: ContentNotFoundError\n' 
```

So the first pdf printed is invalid, but as the report is printed the asset is commited in db and the next print will be valid.


If you use kwkhtmltopdf, as the pdf is not generated (kwkhtmltopdf is more strict), then you have an error instead of a broken pdf and the asset is not commit, so you printing is always broken. (note before that PR https://github.com/odoo/odoo/pull/104594, the asset was commited at the end even if we had an error)






# Desired behavior after PR is merged:

The first print is ok, kwkhtmltopdf is always working


# Note

A better implementation for the report will be to isolate the asset generation in a new cursor, to avoid commiting in the current cursor, but this is a bigger task.


@rco-odoo @pivi-odoo @nboulif @Julien00859 @vrenaville @sbidoul @pedrobaeza @legalsylvain 

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#108261