The Luxembourg tax reporting test was updated to reflect the current 2023 tax rates used by the OSS module. This helps keep automated checks aligned with the latest tax setup and prevents false test failures.

In https://github.com/odoo/odoo/commit/e7edd71a3a4d8d7297c07f44b6b701052f2c5b7d the LU taxes in the OSS module where updated in the odoo repo in 14.0, but in 15.0 a test was added in the enterprise repo, still using the old taxes.

This change updates the test to use the new taxes for 2023.

task-3159138

Related: https://github.com/odoo/odoo/pull/111286

We want to reuse the purchase.order matching logic to enhance vendor bill created for the OCR in documents (EDI, PDF,..). This code has been move to the purchase module. task-id: 2828521 Forward-Port-Of: odoo/enterprise#36461

We want to reuse the purchase.order matching logic to enhance vendor bill created for the OCR in documents (EDI, PDF,..).

This code has been move to the purchase module.

task-id: 2828521

Forward-Port-Of: odoo/enterprise#36461

Avatax stopped providing free trials. Instead users should now use a shared partner sandbox account. The sandbox account will have a single company and in that company the document codes for the invoices (field `avatax_unique_code`, e.g. Journal Entry 1) must be unique. If an invoice with the same document code is submitted Avatax will return an "Invalid DocStatus" error. The `avatax_unique_code` is created using the database ID, so across different Odoo instances there will be collisions. In

Avatax stopped providing free trials. Instead users should now use a shared partner sandbox account. The sandbox account will have a single company and in that company the document codes for the invoices (field `avatax_unique_code`, e.g. Journal Entry 1) must be unique. If an invoice with the same document code is submitted Avatax will return an "Invalid DocStatus" error. The `avatax_unique_code` is created using the database ID, so across different Odoo instances there will be collisions.

In order to work around this Avatax recommend we switch to the "createoradjust" endpoint [1]. It's a drop-in replacement for "create" that will updated even committed invoices. It only errors when an invoice is reported to a tax authority, but that will never happen in a sandbox environment.

This commit uses that endpoint in sandbox mode. For production nothing changes.

[1] https://developer.avalara.com/api-reference/avatax/rest/v2/methods/Transactions/CreateOrAdjustTransaction

opw-3152188

PR note: only targeting v16 since that's where this is most needed (for sales demos etc.). I want to avoid needlessly changing the previous versions.

Forward-Port-Of: odoo/enterprise#36504

Often we have one account for connecting to a web service (e.g. sending invoices to the gov) and as it can be different per company. The credentials fields are stored on the company but there is no security groups=`'base.group_system'` , so these are visible by every user, because `res_company` fields can be seen by everyone.  This commits adds `groups='base.group_system'` on credentials fields. This also requires a `sudo()` whenever we call these fields. task-3044048 Forward-Port-Of: odoo/e

Often we have one account for connecting to a web service (e.g. sending invoices to the gov) and as it can be different per company. The credentials fields are stored on the company but there is no security groups=`'base.group_system'` , so these are visible by every user, because `res_company` fields can be seen by everyone.  This commits adds `groups='base.group_system'` on credentials fields. This also requires a `sudo()` whenever we call these fields.

task-3044048

Forward-Port-Of: odoo/enterprise#36487
Forward-Port-Of: odoo/enterprise#36385

Module was written in French while we want the code to be in English. Also some translations were on Transifex on 15.0 and got lost in the transition to 16.0 since we have no Transifex project for them anymore. This PR translates the module to English and reintroduce lost translations for French and Dutch. We also remove i18n_extra that is both incorrect (wrong module name) and outdated. Task: 3127437 Forward-Port-Of: odoo/enterprise#35268

Module was written in French while we want the code to be in English.
Also some translations were on Transifex on 15.0 and got lost in the transition to 16.0
since we have no Transifex project for them anymore.
This PR translates the module to English and reintroduce lost translations for French and Dutch.
We also remove i18n_extra that is both incorrect (wrong module name) and outdated.

Task: 3127437

Forward-Port-Of: odoo/enterprise#35268

latam 729 ---- unit tests for https://github.com/odoo/odoo/pull/84350 This new unit tests add vendor bill and vendor refund of doc type 186 (liquido producto) and ensure that the purchase vat book is correctly generated. Forward-Port-Of: odoo/enterprise#33188 Forward-Port-Of: odoo/enterprise#24561

latam 729
----

unit tests for https://github.com/odoo/odoo/pull/84350

This new unit tests add vendor bill and vendor refund of doc type 186 (liquido producto) and ensure that the purchase vat book is correctly generated.

Forward-Port-Of: odoo/enterprise#33188
Forward-Port-Of: odoo/enterprise#24561

This commit sets `field_values` to an empty dict in case it's `None` and checks if fields exist in the dictionary before retrieving the values. Without this, rendering the template may result in an error. Forward-Port-Of: odoo/enterprise#36485 Forward-Port-Of: odoo/enterprise#36465

This commit sets `field_values` to an empty dict in case it's `None` and checks if fields exist in the dictionary before retrieving the values. Without this, rendering the template may result in an error.

Forward-Port-Of: odoo/enterprise#36485
Forward-Port-Of: odoo/enterprise#36465

Issue: - When any company creates the UoM record it stores the current company country code in `l10n_co_edi_country_code`. - Ex. A 'US' company creates the UoM record so the value stored in 'l10n_co_edi_country_code' is 'US', then we switch the company to 'CO' company, then still that record 'l10n_co_edi_country_code' value is 'US' because of that the `l10n_co_edi_ubl` field attrs not working correctly. So In this commit, we have removed attrs from the `Colombia Código UBL` fiel

Issue:
- When any company creates the UoM record it stores the current company country
  code in `l10n_co_edi_country_code`.
- Ex. A 'US' company creates the UoM record so the value stored in
  'l10n_co_edi_country_code' is 'US', then we switch the company to 'CO' company,
  then still that record 'l10n_co_edi_country_code' value is 'US' because of that
  the `l10n_co_edi_ubl` field attrs not working correctly.

So In this commit, we have removed attrs from the `Colombia Código UBL` field so
it's displayed in every company.

TaskID - 2784512

Forward-Port-Of: odoo/enterprise#36454
Forward-Port-Of: odoo/enterprise#27435

Before this commit, when relinking a social account, a traceback was raised because an RPC call is made on the wrong model (`social_media` instead of `social.media`). opw-3119581 Forward-Port-Of: odoo/enterprise#36438

Before this commit, when relinking a social account, a traceback was
raised because an RPC call is made on the wrong model
(`social_media` instead of `social.media`).

opw-3119581

Forward-Port-Of: odoo/enterprise#36438

…company not set in chart before this commit, on creating a consolidation journal with consolidation chart in which no companies are set, is raising the access right error. * Consolidation -> Configuration - > Consolidation * create a consolidation and leave companies field empty * now click on periods smart button and enter the necessary details and save * click Edit smart button from period's form * click add a column from the screen and enter name and click save after this comm

…company not set in chart

before this commit, on creating a consolidation journal with consolidation chart in which no companies are set, is raising the access right error.

* Consolidation -> Configuration - > Consolidation
* create a consolidation and leave companies field empty
* now click on periods smart button and enter the necessary details and save
* click Edit smart button from period's form
* click add a column from the screen and enter name and click save


after this commit, no access right error will be raised and allow to create consolidated journals.


https://user-images.githubusercontent.com/27989791/214810251-27e2db33-9d5c-43bf-848b-70c2a48d5465.mp4

Forward-Port-Of: odoo/enterprise#36307

This revision is related to odoo/enterprise#34752 When a `<t>` node with a `groups` attribute is set in a view, this `<t>` block must remain, whatever the case, so the view sent to the web client with Studio represents the actual view in the backend. This is so the xpath computed by Studio is based on the same blocks in the actual view in the database then what is sent by `get_views`. It was already the case when the user did not have the group, but it wasn't the case when the user had t

This revision is related to odoo/enterprise#34752

When a `<t>` node with a `groups` attribute is set in a view, this `<t>` block must remain, whatever the case,
so the view sent to the web client with Studio represents the actual view in the backend.
This is so the xpath computed by Studio is based on the same blocks in the actual view in the database then what is sent by `get_views`.

It was already the case when the user did not have the group, but it wasn't the case when the user had the group. In such a case the call to super was done with the `groups` attribute left, and the call to super therefore removed the `<t>` block itself (moving its content out of it first).

This revision solves the below use case:

Steps to reproduce:

- Install Sales, CRM and studio
- Go to Sales > Orders > Sales Teams
- Now activate studio, and try to modify the progressbar widget.

Issue:

We are going to receive an error message and we will be unable to change ths widget.

opw-3106068

closes odoo/odoo#111111

Forward-Port-Of: odoo/enterprise#36460

…sifex Some translations were lost when we changed to 16.0 since there is no l10n_* project for 16.0 on Transifex. Reintroduced lost translations for Arabic, German, French, Italian, Dutch and Chinese. Task: 3083996 Forward-Port-Of: odoo/enterprise#35270

…sifex

Some translations were lost when we changed to 16.0 since there is no l10n_* project for 16.0 on Transifex. Reintroduced lost translations for Arabic, German, French, Italian, Dutch and Chinese.

Task: 3083996

Forward-Port-Of: odoo/enterprise#35270

Steps to reproduce: - Activate the discount in the Sales settings; - Create a SO with a product that can be rented; - Add a discount and confirm the order; - Validate the pickup. Current behaviour: The discount disappears on the SO line. Expected behaviour: The discount remains on the SO line. This commit prevents updating the `product_uom_qty` of the line if the delivered quantity does not become larger than set on the SO line. The reason is that a change in the `product_uom_qty`

Steps to reproduce:
- Activate the discount in the Sales settings;
- Create a SO with a product that can be rented;
- Add a discount and confirm the order;
- Validate the pickup.

Current behaviour:
The discount disappears on the SO line.

Expected behaviour:
The discount remains on the SO line.

This commit prevents updating the `product_uom_qty` of the line if the delivered quantity does not become larger than set on the SO line. The reason is that a change in the `product_uom_qty` triggers a compute of the SOL price that does not take the discount into account.

OPW-3146922

Forward-Port-Of: odoo/enterprise#36421
Forward-Port-Of: odoo/enterprise#36410

When generating a BOE 349 Spanish tax report with the "Trimester monthly report" option enabled, and if there are refunds included in the report period, you will get an empty traceback. The reason this happens is that when that report option is enabled, it will reduce the `date_to` of the report filter by 1 month (because that's what that feature does). A `_get_mod_period_and_year` call later on uses `date_from` and `date_to` to determine the year and period and the period calculation will fail

When generating a BOE 349 Spanish tax report with the "Trimester monthly report" option enabled, and if there are refunds included in the report period, you will get an empty traceback. The reason this happens is that when that report option is enabled, it will reduce the `date_to` of the report filter by 1 month (because that's what that feature does). A `_get_mod_period_and_year` call later on uses `date_from` and `date_to` to determine the year and period and the period calculation will fail and return None because it's not aware of the modification. Later on when the period is used and subscripted it will give the traceback.

The solution used here uses the `options` dict to keep the original `date_to` for `_get_mod_period_and_year` to use. A cleaner solution could be to simply pass `year` and `period` to `_mod_349_write_type2_refund_records` in `_boe_export_mod349` so the `_get_mod_period_and_year` call isn't needed anymore. But this requires modifying the function signature for `_mod_349_write_type2_refund_records`.

The traceback being empty is a separate issue, I've seen many different kinds of errors occur and they all end up showing as blank. To be fixed in a different PR.

Steps to reproduce
1. Start from a clean 14.0 database
2. Set the default company to have Spain as the country
3. Install Accounting and Contacts
4. In Contacts, create a new company contact called Odoo and its country to Belgium. What matters is that the country is European but not Spain. Set the VAT number to BE0477472701.
5. Switch to the default ES Company that got added after installing Accounting
6. In Accounting, create a customer invoice for the Odoo contact with some random product that has a price. Set the invoice date to somewhere in Q4 2022 (like 15 November 2022). In the AEAT data tab, set the type for mod 349 to "A - Acquisition".
7. Revert the customer invoice as a full refund and with the same date as the invoice.
8. In Accounting, go to Reporting -> Tax Report (Mod 349), and set the date filter to the last trimester (currently Q4 2022). You should see an amount on the line "A. Adquisiciones intracomunitarias sujetas" under "Reembolsos".
9. Press the "Export (BOE)" button, and check "Trimester monthly report". Click "Generate BOE".
10. Empty traceback

opw-3131030

Forward-Port-Of: odoo/enterprise#36419
Forward-Port-Of: odoo/enterprise#36228

Same issue as in d0e3d2496bc1f99ae110f6abc46c176d874df223 Owl 2.0.3 properly escapes backslashes when generating block strings [1]. As a consequence, the non breakable spaces used in the legacy grid views now get escaped and are displayed as text. This commit ensures they're correctly evaluated as html. [1] odoo/owl@530c2f9 Forward-Port-Of: odoo/enterprise#36426

Same issue as in d0e3d2496bc1f99ae110f6abc46c176d874df223
    
Owl 2.0.3 properly escapes backslashes when generating block
strings [1]. As a consequence, the non breakable spaces used in
the legacy grid views now get escaped and are displayed as text.
This commit ensures they're correctly evaluated as html.
    
[1] odoo/owl@530c2f9

Forward-Port-Of: odoo/enterprise#36426

…0/Transifex Some translations were lost when we changed version to 16.0 since there is no l10n_* project for 16.0 on Transifex. Reintroduced lost translations for German, Dutch and French. Task: 3120851 Forward-Port-Of: odoo/enterprise#35262

…0/Transifex

Some translations were lost when we changed version to 16.0 since there is no l10n_* project for 16.0 on Transifex.
Reintroduced lost translations for German, Dutch and French.

Task: 3120851

Forward-Port-Of: odoo/enterprise#35262

This reduces the feed refresh ribbon height that was too big and lighten its hover/focus color. Technical note: the ribbon uses a bootstrap alert which has more padding in 16.0 than in previous versions. To solve the problem, we have forced the padding to a similar value using a bootstrap class (py-2). Also removed the hover color change (based on color-contrast) because it was not great in dark mode. Task-3105171 Forward-Port-Of: odoo/enterprise#36405

This reduces the feed refresh ribbon height that was too big and lighten its hover/focus color.

Technical note: the ribbon uses a bootstrap alert which has more padding in 16.0 than in previous versions. To solve the problem, we have forced the padding to a similar value using a bootstrap class (py-2). Also removed the hover color change (based on color-contrast) because it was not great in dark mode.

Task-3105171

Forward-Port-Of: odoo/enterprise#36405

Steps to reproduce: - Install Manufacturing - Manufacturing > Settings > Enable Work Orders - Manufacturing Orders > Create order for Table > Confirm > Work orders tab > Open Tablet View - Get to any step where you register components - Change the quantity to produce - Pause > Continue Issue: The quantity to produce is reset to the original amount. Solution: Do not recompute qty_done when the workorder is paused. Productivity line conditions taken from `_prepare_timeline_vals`

Steps to reproduce:
- Install Manufacturing
- Manufacturing > Settings > Enable Work Orders
- Manufacturing Orders > Create order for Table > Confirm > Work orders tab > Open Tablet View
- Get to any step where you register components
- Change the quantity to produce
- Pause > Continue

Issue:
The quantity to produce is reset to the original amount.

Solution:
Do not recompute qty_done when the workorder is paused.

Productivity line conditions taken from `_prepare_timeline_vals`

opw-3032052

Forward-Port-Of: odoo/enterprise#35867
Forward-Port-Of: odoo/enterprise#34763

8700 Muut liikekulut (other expenses) appears under I.XII.1 Luottotappiot (credit losses), as there is already a dedicated account for that (8730 Myynnin luottotappiot (credit losses on sales)), we add a section for other expenses. opw-2702912 Forward-Port-Of: odoo/enterprise#36389 Forward-Port-Of: odoo/enterprise#35813

8700 Muut liikekulut (other expenses) appears
under I.XII.1 Luottotappiot (credit losses),
as there is already a dedicated account for
that (8730 Myynnin luottotappiot (credit losses
on sales)), we add a section for other expenses.

opw-2702912

Forward-Port-Of: odoo/enterprise#36389
Forward-Port-Of: odoo/enterprise#35813

Currently, even entries before lock dates are shown with the alert for bank lines not linked to a statement. But they can't modify the lines before lock date so, we should not raise the alert and show them here. task-3135707 Forward-Port-Of: odoo/enterprise#36019

Currently, even entries before lock dates are shown with the alert for bank lines not linked to a statement.
But they can't modify the lines before lock date so, we should not raise the alert and show them here.

task-3135707

Forward-Port-Of: odoo/enterprise#36019

This commit changes the manifest of the l10n_lu_reports module top include a brief descritpion of the SAF-T file format. task-2667705 Forward-Port-Of: odoo/enterprise#35062

This commit changes the manifest of the l10n_lu_reports module top include a brief descritpion of the SAF-T file format.

task-2667705

Forward-Port-Of: odoo/enterprise#35062

Forward-Port-Of: odoo/enterprise#36463

Forward-Port-Of: odoo/enterprise#36463

The `_l10n_mx_edi_cron_update_sat_status` cron has to post lots of requests to the mx gov SAT portal. These post requests can take quite some time and in some cases lead to a TimeoutError and a complete rollback. To avoid losing already posted requests and processed responses the edi.documents to process are split in batch of 50. The transaction is committed after each batch so that the already processed batches are not rollbacked on Timeout. opw-3018561-avd Forward-Port-Of: odoo/enterpri

The `_l10n_mx_edi_cron_update_sat_status` cron has to post lots of requests to the mx gov SAT portal. These post requests can take quite some time and in some cases lead to a TimeoutError and a complete rollback.

To avoid losing already posted requests and processed responses the edi.documents to process are split in batch of 50. The transaction is committed after each batch so that the already processed batches are not rollbacked on Timeout.

opw-3018561-avd

Forward-Port-Of: odoo/enterprise#34521