This fix ensures spreadsheet chart trendlines receive the correct axis information when charts are created or edited. Business users get more accurate chart visuals, reducing confusion when reviewing spreadsheet reports and dashboards.

This commit resolves a UI bug in chart trendlines by ensuring AxisType is
properly passed from the web client to Odoo charts.

Task: [4743602](https://www.odoo.com/odoo/2328/tasks/4743602)

The YouTube posting form now keeps the selected video category when a post is published. This prevents category information from being accidentally lost and helps ensure uploaded videos are saved with the intended classification.

If not specified, the field `youtube_video_category_id` was treated as readonly by default. This commit explicitly sets readonly: false, ensuring that the field is editable. This prevents the value from being lost during posting, as it will now be correctly written to the database.

Part of PR: #83571
opw-4646432

Task: 4640948 Currently, a sales user with no stock permissions can see the little forecast icon and, upon clicking on it, a link to the forecast report. However, trying to access the report results in an "Access Error" message. The forecast report is important for sales users. This commit will allow them to access the report, but without the option to edit stock pickings (reserve/unreserve buttons). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.

Task: 4640948

Currently, a sales user with no stock permissions can see the little
forecast icon and, upon clicking on it, a link to the forecast report.
However, trying to access the report results in an "Access Error"
message.

The forecast report is important for sales users. This commit will allow
them to access the report, but without the option to edit stock pickings
(reserve/unreserve buttons).




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

Forward-Port-Of: odoo/odoo#205513

When generating a credit note for an invoice with multiple lines of the same product (same product_id, name, and price_unit) but different discounts, the system incorrectly matches both credit note lines to the same invoice line. This commit solves this issue by adding line discount to the criteria used to match credit notes lines with invoices lines. task-4876849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo

When generating a credit note for an invoice with multiple lines of the same product
(same product_id, name, and price_unit) but different discounts,
the system incorrectly matches both credit note lines to the same invoice line.
This commit solves this issue by adding line discount to
the criteria used to match credit notes lines with invoices lines.

task-4876849




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

Forward-Port-Of: odoo/odoo#214779

Steps to reproduce - open a record from Contacts app - from chatter, click `send mail` , open full mail composer - add a attachment - schedule a message, by clicking '▼' on send message - Again from chatter, click on edit the same message - try to add another attachment Observation: A traceback is received Issue: Currently, `onFileUploaded` function attempts to get `res_ids` from `data`, https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/static

Steps to reproduce
- open a record from Contacts app
- from chatter, click `send mail` , open full mail composer
- add a attachment
- schedule a message, by clicking '▼' on send message
- Again from chatter, click on edit the same message
- try to add another attachment

Observation:
A traceback is received

Issue:
Currently, `onFileUploaded` function attempts to get `res_ids` from `data`, 
https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/static/src/core/web/mail_composer_attachment_selector.js#L25-L30

but in case message is scheduled, which is stored in `mail.scheduled.message` ,when editing it we do not have `res_ids` 
https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/wizard/mail_compose_message.py#L120

instead we have `res_id` field, 
https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/models/mail_scheduled_message.py#L46
hence a traceback is received when trying to json parse a `undefined` value.

Fix:
Adapt the `onFileUploaded` function to consider both, `res_ids` and `res_id`

opw-4839926


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

Forward-Port-Of: odoo/odoo#212960

Calling external resources can lead to random failures in tests test_tracking_short_code calls a tracked url to check the side effect of this call, but we actually don't need to follow the redirect. Fixes the test by not following the 301 and checking the target instead. Forward-Port-Of: odoo/odoo#215232 Forward-Port-Of: odoo/odoo#215175

Calling external resources can lead to random failures in tests

test_tracking_short_code calls a tracked url to check the side effect of this call, but we actually don't need to follow the redirect.

Fixes the test by not following the 301 and checking the target instead.

Forward-Port-Of: odoo/odoo#215232
Forward-Port-Of: odoo/odoo#215175

Before this change, the column % VAT in Argentinean Legal PDF translation to Spanish was not working (Was always showing "% VAT" column title) With this change will show "% IVA" when printing in Spanish ### Description of the issue/feature this PR addresses: Bad Spanish translation on the Column % VAT in the Argentinean Legal PDF Report 1. Install Argentinean - Accounting module 2. Install Spanish language 3. Log into to one of the demo Argentinean Companys : (AR) Responsable Inscr

Before this change, the column % VAT in Argentinean Legal PDF translation to Spanish was not working (Was always showing "% VAT" column title)

With this change will show "% IVA" when printing in Spanish

### Description of the issue/feature this PR addresses:

Bad Spanish translation on the Column % VAT in the Argentinean Legal PDF Report

1. Install Argentinean - Accounting module
2. Install Spanish language
3. Log into to one of the demo Argentinean Companys : (AR) Responsable Inscripto
4. Go to the Cutomer invoices menu and select any of the invoices already created in demo data
5. Go to the partner and change the Languaje to Spanish
6. Return to the invoice and print the PDF

### Current behavior before PR:

All the other terms are translated, but not the % VAT column
![image](https://github.com/user-attachments/assets/ba727710-5b15-45ed-83b6-fd285cf37697)

### Desired behavior after PR is merged:

All the terms are correctly translated
![image](https://github.com/user-attachments/assets/233ab5de-f00f-43df-aa24-3517f40cd5c7)


References LATM 1343 | ADHOC 50766
 
---
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: https://github.com/odoo/odoo/pull/206869

Forward-Port-Of: odoo/odoo#214143
Forward-Port-Of: odoo/odoo#213501

See odoo/odoo#214960 (master) The PR mentioned above adds fixes to connect to a DB that is part of a multi-DB instance. This includes saving a new configuration key, `db_name`, to keep track of the current database name. This commit backports just this functionality, making older versions compatible with the new pairing token that includes to DB name. This prevents a potential traceback if using this new token format. task-4815521 --- I confirm I have signed the CLA and read the PR

See odoo/odoo#214960 (master)

The PR mentioned above adds fixes to connect to a DB that is part of a multi-DB instance. This includes saving a new configuration key, `db_name`, to keep track of the current database name.

This commit backports just this functionality, making older versions compatible with the new pairing token that includes to DB name. This prevents a potential traceback if using this new token format.

task-4815521

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

Forward-Port-Of: odoo/odoo#215286
Forward-Port-Of: odoo/odoo#215243

**Steps to reproduce:** 1. Install the website_sale app. 2. Import a user with trailing spaces in the Name field. 3. Make this user Admin in settings 4. Log in with that user and go to Website > Shop. 5. Click on new and create a new product 6. Add this product to the cart and proceed to checkout. 7. The checkout form pre-fills the name (with trailing spaces). 8. fill other fields 9. Submitting the form triggers a warning due to changed name. **Expected behaviour:** - Name is not ch

**Steps to reproduce:**
1. Install the website_sale app.
2. Import a user with trailing spaces in the Name field.
3. Make this user Admin in settings
4. Log in with that user and go to Website > Shop.
5. Click on new and create a new product
6. Add this product to the cart and proceed to checkout.
7. The checkout form pre-fills the name (with trailing spaces).
8. fill other fields
9. Submitting the form triggers a warning due to changed name.

**Expected behaviour:**
- Name is not changed by us so it should let us checkout
- There should not be trailing spaces in imported char fields
  if trim attribute is true

**Issue:**
- The name field from the form is trimmed in post request,
  but the value from the database (with trailing spaces) is used during comparison
  This results in a false positive change detection.

- User's name with trailing spaces is because of Imported records does not check for
  trim attribute in backend but this is handled in ui.

**Solution:**
- Trim the database value before comparing it to the form input
- Trim the values of char field before importing if trim attribute is true

opw-4794220

Forward-Port-Of: odoo/odoo#212040

**Current behavior before PR:** - When a list contains content separated by **Shift+Enter** toggling the list would break these lines and create a separate base container for each segment separated by `<br>`. **Desired behavior after PR is merged:** - Only a single base container is created when toggling a list that contains **Shift+Enter** contents. task:4854372 Forward-Port-Of: odoo/odoo#213546

**Current behavior before PR:**

- When a list contains content separated by **Shift+Enter** toggling the list would break these lines and create a separate base container for each segment separated by `<br>`.

**Desired behavior after PR is merged:**

- Only a single base container is created when toggling a list that contains **Shift+Enter** contents.

task:4854372

Forward-Port-Of: odoo/odoo#213546

Currently, when a loyalty program has expired, loyalty card are still getting created even though points are not granted. Steps to reproduce: ------------------- * Create a loyatly program and make it sot that is has already expired * Open pos and make an order selecting any customer * Go to the backend and check the loyalty program > Observation: 1 card has been created with 0 points Why the fix: ------------ Not loading the expired programs prevent the creation of loyalty cards.

Currently, when a loyalty program has expired, loyalty card are still getting created even though points are not granted.

Steps to reproduce:
-------------------
* Create a loyatly program and make it sot that is has already expired
* Open pos and make an order selecting any customer
* Go to the backend and check the loyalty program
> Observation: 1 card has been created with 0 points

Why the fix:
------------
Not loading the expired programs prevent the creation of loyalty cards.

Using the same logic as module `sale_loyalty`
https://github.com/odoo-dev/odoo/blob/5acb89b8ba9be0e18bca65e26c03f47199fcfb4b/addons/sale_loyalty/models/sale_order.py#L461-L465

opw-4671522

Forward-Port-Of: odoo/odoo#208701
Forward-Port-Of: odoo/odoo#208134

Steps to reproduce: 1. Install l10n_gcc_pos. 2. Set the company’s country to a GCC country. 3. Print a POS receipt. Issue: - The receipt displays the phrase 'Served by' multiple times first two hardcoded and third one from prefix due to the cashier prop already including the prefix 'Served by '. - https://github.com/odoo/odoo/blob/f2dc7b5aaaf60d23e42e92f1ca0c6eed4ea13bf2/addons/l10n_gcc_pos/static/src/overrides/app/screens/receipt_screen/receipt/order_receipt.xml#L22 - Standard header

Steps to reproduce:
1. Install l10n_gcc_pos.
2. Set the company’s country to a GCC country.
3. Print a POS receipt.

Issue:
- The receipt displays the phrase 'Served by' multiple times first two hardcoded and third one from prefix due to the cashier prop already including the prefix 'Served by '.
- https://github.com/odoo/odoo/blob/f2dc7b5aaaf60d23e42e92f1ca0c6eed4ea13bf2/addons/l10n_gcc_pos/static/src/overrides/app/screens/receipt_screen/receipt/order_receipt.xml#L22

- Standard header data
https://github.com/odoo/odoo/blob/0f8546528566acbcd2dd2fc1a99ae148ea2a7895/addons/point_of_sale/static/src/app/store/pos_store.js#L2099-L2105

Solution:
- Replace cashier prop with gcc_cashier to return only the cashier’s name, without the 'Served by ' prefix. This avoids duplication and allows the template to handle translations consistently.

opw-4724578

Forward-Port-Of: odoo/odoo#212299

Problems: The error message for unbalanced journal entries in the "Miscellaneous Operations" journal was unnecessarily complex and misleading. It suggested setting a default account on the journal to automatically balance entries, but this auto-balancing was intended only for lines with taxes. Furthermore, the method _get_automatic_balancing_account in account.move was ignoring any default account set on the journal itself when auto-balancing because of taxes. It was instead always taking th

Problems:
The error message for unbalanced journal entries in the "Miscellaneous Operations" journal was unnecessarily complex and misleading. It suggested setting a default account on the journal to automatically balance entries, but this auto-balancing was intended only for lines with taxes.

Furthermore, the method _get_automatic_balancing_account in account.move was ignoring any default account set on the journal itself when auto-balancing because of taxes. It was instead always taking the company suspense account.

How to reproduce the issue:

- Add a default account to the miscellaneous journal.
- Create a journal entry manually, and add a line with any account of 100 debit.
- Attempt to save.

Finally, this commit also set the account_id of new account move lines to the default account id of the journal if it exists when creating a journal entry.

enterprise pr: https://github.com/odoo/enterprise/pull/86987

opw-4751270



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

Forward-Port-Of: odoo/odoo#211443

Fixed an issue where, when canceling a payment that originated the third-party check, the check remained in "In Hand" status when it shouldn't. Now, when the payment is canceled, the check status is properly updated to reflect its cancellation, ensuring consistency in the workflow. **Description of the issue/feature this PR addresses:** This PR addresses an issue where a third-party check remains in the "In Hand" status even after the origin payment is canceled. **Current behavior b

Fixed an issue where, when canceling a payment that originated the third-party check, the check remained in "In Hand" status when it shouldn't. 
Now, when the payment is canceled, the check status is properly updated to reflect its cancellation, ensuring consistency in the workflow.


**Description of the issue/feature this PR addresses:**

This PR addresses an issue where a third-party check remains in the "In Hand" status even after the origin payment is canceled.

**Current behavior before PR:**

A customer payment is created with a third-party check.

The payment is confirmed, then moved to draft and canceled.

After cancellation, the third-party check remains in the "In Hand" status in the third-party checks menu, even though the origin payment has been canceled.

**Desired behavior after PR is merged:**

When the payment is canceled, the check will no longer remain in "In Hand" status in the third-party checks menu after the payment is canceled.



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

Forward-Port-Of: odoo/odoo#214071

The Italian Law requires cash payments to be rounded up to 5 cents (art. 13 del D.Lgs. 231/2007, updated in 2018). The exported XML invoice didn't have any cash rounding lines and so the sum was wrong in ImportoTotaleDocumento. This was happening because cash rounding lines (`display_type == 'rounding'`) were excluded during the export function's computation. This fix makes the function include `rounding` lines into the computation, making the invoice compliant. Steps: 1. Activate cash ro

The Italian Law requires cash payments to be rounded up to 5 cents (art. 13 del D.Lgs. 231/2007, updated in 2018). The exported XML invoice didn't have any cash rounding lines and so the sum was wrong in ImportoTotaleDocumento. This was happening because cash rounding lines (`display_type == 'rounding'`) were excluded during the export function's computation.

This fix makes the function include `rounding` lines into the computation, making the invoice compliant.

Steps:
1. Activate cash rounding management.
2. Create a `0.05E` cash rounding.
3. Create an invoice with a total that is not rounded.
4. Set up the cash rounding on the invoice:
      Other information > Cash rounding method
   An invoice cash rounding line will be created, the total will be rounded.
5. Generate the XML and download it.
6. The amount in `ImportoTotaleDocumento` tag will not match the total of the invoice.  


Task [link](https://www.odoo.com/odoo/project/967/tasks/4816355)
task-4816355

Forward-Port-Of: odoo/odoo#213337

When scanning the barcode of a loyalty card, there was an error saying the code is invalid. Instead it should select the partner linked to the card if there is one. Steps to reproduce: ------------------- * Create a loyalty program, and a loyalty card with a partner * Copy the barcode of the loyalty card * Open the POS, and scan the barcode of the loyalty card > Observation: The error "Invalid code" appears, and the partner is not selected opw-4653983 Forward-Port-Of: odoo/odoo#21

When scanning the barcode of a loyalty card, there was an error saying the code is invalid. Instead it should select the partner linked to the card if there is one.

Steps to reproduce:
-------------------
* Create a loyalty program, and a loyalty card with a partner
* Copy the barcode of the loyalty card
* Open the POS, and scan the barcode of the loyalty card
> Observation: The error "Invalid code" appears, and the partner is not
  selected

opw-4653983

Forward-Port-Of: odoo/odoo#213831

This commit reverts odoo/odoo#208302, odoo/odoo#188848 and odoo/odoo#192876. Issues have been found on the synchronization with Google related to the duplication of events for synchronized users. As it is an urgent matter and these two fixes were merged too close to prior of the first problem report, we're dropping them for additional investigation. task-4873605 Forward-Port-Of: odoo/odoo#215449

This commit reverts odoo/odoo#208302, odoo/odoo#188848 and odoo/odoo#192876.

Issues have been found on the synchronization with Google related to the duplication of events for synchronized users. As it is an urgent matter and these two fixes were merged too close to prior of the first problem report, we're dropping them for additional investigation.

task-4873605

Forward-Port-Of: odoo/odoo#215449

Steps to reproduce: - create a new journal with foreign currency - create an invoice (amount:100) with this journal and set it "to check" - Go to dashboard Issue: check balance is in company currency amount but the symbol is the one from the currency of the journal Solution: Chkl: <strike>Misc and Sales/Purchase Journals should display all amounts in company currency</strike> Eventually, we decided that it would be better for the stable versions to keep the currency displayed as the

Steps to reproduce:
- create a new journal with foreign currency
- create an invoice (amount:100)  with this journal and set it "to check"
- Go to dashboard

Issue:
check balance is in company currency amount but the symbol is the one from the currency of the journal

Solution:
Chkl: <strike>Misc and Sales/Purchase Journals should display all amounts in company currency</strike>
Eventually, we decided that it would be better for the stable versions to keep the currency displayed as the one from the journals.
We therefore use the same logic as for the bill/invoices

opw-4349684

Forward-Port-Of: odoo/odoo#210835
Forward-Port-Of: odoo/odoo#203475

Allow batch write on model using the `HtmlFieldHistory` mixin. task-4852381 task-4731389 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213116

Allow batch write on model using the `HtmlFieldHistory` mixin.

task-4852381
task-4731389


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

Forward-Port-Of: odoo/odoo#213116

Currently, an error occurs when finding duplicate transactions in the bank. Steps to Reproduce: - Install the `accountant` module. - In `Accounting Dashboard`, click on `Bank`. - In Actions, click `Find Duplicate Transactions`. - Clear the `Starting Date` field and click save. `TypeError: unsupported operand type(s) for -: 'bool' and 'relativedelta'` This error occurs when the system attempts to find duplicate transactions without a Starting Date. When finding duplicate transa

Currently, an error occurs when finding duplicate transactions in the bank.

Steps to Reproduce:

 - Install the `accountant` module.
 - In `Accounting Dashboard`, click on `Bank`.
 - In Actions, click `Find Duplicate Transactions`.
 - Clear the `Starting Date` field and click save.

`TypeError: unsupported operand type(s) for -: 'bool' and 'relativedelta'`

This error occurs when the system attempts to find duplicate transactions without a Starting Date. When finding duplicate transactions, it tries to calculate the `prior_date` using `date_from - relativedelta(months=3)` [1]. However, since `date_from` is `False`, this raises an error.

[1] https://github.com/odoo/enterprise/blob/acdba5ecf89ee8920f82e07e16fac2a0f9659b12/account_online_synchronization/models/account_journal.py#L314

This commit ensures that if the Starting Date is empty when finding duplicate transactions, it uses today’s date as the Starting Date.

sentry-6653835511

Forward-Port-Of: odoo/enterprise#87000

Bug: 1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top. 2. Casual loading rate applies to Overtime hours. Steps to reproduce: 1. Create a payslip for an employee with a contract of Fixed wage of 2000 per week. 2. The created payslip is of correct amount with the standard 40-hours work week. 3. Add a work entry of type Overtime with duration of 4 hours. Recompute the worked days amounts. Current behavior: The total remain

Bug:
1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top.

2. Casual loading rate applies to Overtime hours.

Steps to reproduce:
1. Create a payslip for an employee with a contract of Fixed wage of 2000 per week.
2. The created payslip is of correct amount with the standard 40-hours work week.
3. Add a work entry of type Overtime with duration of 4 hours. Recompute the worked days amounts.

Current behavior:
The total remains 2000 and the computed hourly rate becomes 2000/44=45.45

Expected behavior:
The hourly rate should remain the same 50.
The total should increase to be:
fixed_wage + hourly_rate * overtime hours
2000 + 50 * 4 = 2200

Fix:
1. While computing the amounts for each worked days type, exclude hours of type Overtime from total hours when calculating the hourly rate.

2.The casual loading rate should not apply to Overtime work entry types.

task-4617681

Forward-Port-Of: odoo/enterprise#83171

There is a bug in the module that made the creation of payslip triggers an error. Steps to reproduce it : 1) Use a Belgian company and an employee with a contract; 2) Create a work entry for a whole month (from 05/01/2025 09:00:00 to 06/01/2025 17:00:00 for example); 3) Try to create a payslip for this employee. Error : File "/data/build/enterprise/l10n_be_hr_payroll/models/hr_contract.py", line 517, in _get_work_hours_split_half work_data[('half', work_entry.work_entry_type_id.id)] +=

There is a bug in the module that made the creation of payslip triggers an error. Steps to reproduce it :
1) Use a Belgian company and an employee with a contract;
2) Create a work entry for a whole month (from 05/01/2025 09:00:00 to 06/01/2025 17:00:00 for example);
3) Try to create a payslip for this employee.

Error :
File "/data/build/enterprise/l10n_be_hr_payroll/models/hr_contract.py", line 517, in _get_work_hours_split_half
	work_data[('half', work_entry.work_entry_type_id.id)] += dt.days * 24 + dt.seconds / 3600  # Number of hours
TypeError: 'float' object is not iterable

[opw-4752109](www.odoo.com/odoo/project/49/tasks/4752109)

Forward-Port-Of: odoo/enterprise#84810

Steps to reproduce: - Install payroll, l10n_mx_hr_payroll (mexican localisation) - Install l10n_mx_hr_payroll_account - Switch to a Mexican Company - Create a payslip for a mexican employee with amount < 4000 - Compute the sheet for the payslip Error message appears, this error message is not a descriptive to the user or not telling what could have gone wrong. This happens because the mexican pay structure has some salary rules that has to be computed, one of these rules is `Retiremen

Steps to reproduce:
- Install payroll, l10n_mx_hr_payroll (mexican localisation)
- Install l10n_mx_hr_payroll_account
- Switch to a Mexican Company
- Create a payslip for a mexican employee with amount < 4000
- Compute the sheet for the payslip

Error message appears, this error message is not a descriptive to the
user or not telling what could have gone wrong. This happens because
the mexican pay structure has some salary rules that has to be
computed, one of these rules is `Retirement, assault in elderly and
old age (CEAV) IMSS (Employer)` that has mode of code. This mode means
calling safe_eval on the code raw text of it written in the xml file
on the data folder. This rule aims to find the suitable taxation level
to be applied on the salary. It reads the limits of each level and
check if the `integrated_daily_wage` of the employee falls in this
level and applies that taxation level. There is no upper limit on the
salary, But there is a min level, hence if the integrated_daily_wage
< mdw (minimum daily wage) the function returns None that used as
index in the taxation table leading to an unreadable Exception from
the safe_eval call.

https://github.com/odoo/enterprise/blob/747482f34ca8210d89d81b3363ec5a8fc3a4ff6f/l10n_mx_hr_payroll/data/salary_rules/hr_salary_rule_regular_pay_data.xml#L1111-L1120

opw-4576482

Forward-Port-Of: odoo/enterprise#83364

The default_get method of the 'l10n_uk.hmrc.send.wizard' model assumed the presence of 'client_data' in the context, leading to a KeyError during test_display_name_new_record. This fix checks for the presence of 'client_data' before attempting to call import_vat_obligations. If 'client_data' is not present, it avoids calling import_vat_obligations and raises a UserError, thus preventing the KeyError. build_error-115767 Forward-Port-Of: odoo/enterprise#84327

The default_get method of the 'l10n_uk.hmrc.send.wizard' model assumed
the presence of 'client_data' in the context, leading to a KeyError
during test_display_name_new_record.

This fix checks for the presence of 'client_data' before attempting to
call import_vat_obligations. If 'client_data' is not present, it avoids
calling import_vat_obligations and raises a UserError, thus preventing the KeyError.

build_error-115767

Forward-Port-Of: odoo/enterprise#84327

### Steps to reproduce: - Create a storable product with 1 unit in stock and a barcode: XXX - Go to the barcode app > Inventory Count - Scan XXX > One line is created 1/1. - Diminish the quantity to 0 > Remove the line - Scan XXX #### > The line appear with multiple sublines #### > If you repeat the two last steps even more sublines will appear ### Cause of the issue: Scaning XXX will create a line with a subline for each quant present in the lazyBarcodeCache: https://github.com

### Steps to reproduce:

- Create a storable product with 1 unit in stock and a barcode: XXX
- Go to the barcode app > Inventory Count
- Scan XXX
> One line is created 1/1.
- Diminish the quantity to 0 > Remove the line
- Scan XXX
#### > The line appear with multiple sublines
#### > If you repeat the two last steps even more sublines will appear

### Cause of the issue:

Scaning XXX will create a line with a subline for each quant present in the lazyBarcodeCache:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_quant_model.js#L345 https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_quant_model.js#L359-L381 However, the quants present in the cache are currently stored in a list and they are pushed to the list by the `setCache` method even if they are already present:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/lazy_barcode_cache.js#L54-L62 This is problematic in the present flow since multiple actions set the cahche and hence add the "new" version of the already present quant rather than updating its current value.

To be more precise, in the present workflow, the `setCache` method is called once during the the first barcode scan:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/lazy_barcode_cache.js#L324-L325 And twice at each line deletion (once per `refreshCache` call, one during the save and one during the `trigger('refresh')`): https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_model.js#L823-L825 https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_model.js#L468-L471

opw-4787229

Forward-Port-Of: odoo/enterprise#87073

This commit removes the default account set in the setup of test_payroll_expense. Because of 67b5fc47ca4aa1abb60f198a87d7784ef400f796 the filter in get_all_amls_to_be_reconciled would get multiples amls instead of only one. community pr: https://github.com/odoo/odoo/pull/211443 opw-4751270 Forward-Port-Of: odoo/enterprise#86987

This commit removes the default account set in the setup of test_payroll_expense. Because of 67b5fc47ca4aa1abb60f198a87d7784ef400f796 the filter in get_all_amls_to_be_reconciled would get multiples amls instead of only one.

community pr: https://github.com/odoo/odoo/pull/211443

opw-4751270

Forward-Port-Of: odoo/enterprise#86987

Before, a fix was done to round column for materials and payments columns but the method was HALF-UP. This should always be DOWN as specified here https://assets.publishing.service.gov.uk/media/5d53df0040f0b6098ead46c2/cis-qsbvr-v2.2.pdf page 28 task-4881298 Forward-Port-Of: odoo/enterprise#88018

Before, a fix was done to round column for materials and payments columns but the method was HALF-UP.

This should always be DOWN as specified here
https://assets.publishing.service.gov.uk/media/5d53df0040f0b6098ead46c2/cis-qsbvr-v2.2.pdf page 28

task-4881298

Forward-Port-Of: odoo/enterprise#88018

Since #82896 reconciling bank statement line that has a partner with company_id set to a branch company leads to removing the partner from the statement line when validating the reconciliation. Steps: - Create a branch company and select it. - Create a contact with company_id == the branch company. - Create and confirm an invoice with that contact as partner. - Go back to accounting dashboard, and open bank reconciliation widget. - Create a new transaction with the invoice amount and tha

Since #82896 reconciling bank statement line that has a partner with company_id set to a branch company leads to removing the partner from the statement line when validating the reconciliation.

Steps:
- Create a branch company and select it.
- Create a contact with company_id == the branch company.
- Create and confirm an invoice with that contact as partner.
- Go back to accounting dashboard, and open bank reconciliation widget.
- Create a new transaction with the invoice amount and that partner.
- Select it, and select the invoice we created, and click on Validate.
- Notice that the partner is not set (removed) from the transaction.

Fix:
Add another condition to check if the statement line company matches the partner company before trying to unset the partner if its company isn't a root company.

opw-4809740

Forward-Port-Of: odoo/enterprise#88034
Forward-Port-Of: odoo/enterprise#87440

Before, The closing balance of saft export for the unaffected earnings account was always at zero which makes no sense. Now this is fixed as the closing balance should always be equal to the initial balance. Forward-Port-Of: odoo/enterprise#88096 Forward-Port-Of: odoo/enterprise#87419

Before, The closing balance of saft export for the unaffected earnings account was always at zero which makes no sense.

Now this is fixed as the closing balance should always be equal to the initial balance.

Forward-Port-Of: odoo/enterprise#88096
Forward-Port-Of: odoo/enterprise#87419

Currently when using Fiskaly, the receipt gets printed with the technical names of the tss values. Steps to reproduce: ------------------- * Set up the db to use fiskaly * Open restaurant * Place and pay an order > Observation: On the receipt screen the name of the tss values are shown as: transaction_number, signature_algorithm, client_serial_number, .... Why the fix: ------------ Beore this commit https://github.com/odoo/enterprise/commit/d1a94147060083da54f9423f8c379676fbb7db66#

Currently when using Fiskaly, the receipt gets printed with the technical names of the tss values.

Steps to reproduce:
-------------------
* Set up the db to use fiskaly
* Open restaurant
* Place and pay an order
> Observation: On the receipt screen the name of the tss values are shown as:
transaction_number, signature_algorithm, client_serial_number, ....

Why the fix:
------------
Beore this commit https://github.com/odoo/enterprise/commit/d1a94147060083da54f9423f8c379676fbb7db66#diff-960ffa6839618d084dd5de6e29458ef68766a31250fc7d296512ec5358f04056 we were using a dictionnary `name, value` when using tss information, cf `_initTssInformation()` in `l10n_de_pos_cert/static/src/overrides/models/models.js`.

We re-introduce this behavior and revert the following commit https://github.com/odoo-dev/enterprise/commit/9f75e3fe092bd838fffb11a35a8d854afff71869 to use the official names instead of the technical ones.

opw-4822342

Forward-Port-Of: odoo/enterprise#87717

When generating the German tax report, field Kz83 was included in the XML even when the value was 0.00. This caused the exported file to be rejected by the ELSTER platform. This fix removes Kz83 from the XML when its value is null or zero. The ELSTER platform automatically calculates this field if it's missing. source: https://help.deltek.com/product/maconomy/documentation/BPMReporting/CountryReports/Appendix_Germany.html opw-4783544 Forward-Port-Of: odoo/enterprise#86978

When generating the German tax report, field Kz83 was included in the XML even when the value was 0.00. This caused the exported file to be rejected by the ELSTER platform.

This fix removes Kz83 from the XML when its value is null or zero. The ELSTER platform automatically calculates this field if it's missing.

source: https://help.deltek.com/product/maconomy/documentation/BPMReporting/CountryReports/Appendix_Germany.html

opw-4783544

Forward-Port-Of: odoo/enterprise#86978

Before this PR: - Fields `l10n_in_exception`, `l10n_in_gst_return_period_id`, and `l10n_in_gstr2b_reconciliation_status` were copied when duplicating records. - The field label for GSTR-2B status was shown as just "Status", which could be ambiguous. After this PR: - Added `copy=False` to all three fields to prevent unintended data duplication. - Updated the label "Status" to "GSTR-2B Status" in `l10n_in.gst.return.period` to make the purpose clear. OPW: 4882698 Forward-Port-Of: odoo/e

Before this PR:
- Fields `l10n_in_exception`, `l10n_in_gst_return_period_id`, and `l10n_in_gstr2b_reconciliation_status` were copied when duplicating records.
- The field label for GSTR-2B status was shown as just "Status", which could be ambiguous.

After this PR:
- Added `copy=False` to all three fields to prevent unintended data duplication.
- Updated the label "Status" to "GSTR-2B Status" in `l10n_in.gst.return.period` to make the purpose clear.

OPW: 4882698

Forward-Port-Of: odoo/enterprise#88110

In the Datev standard export, sales with foreign currency and currency indicator are exported to the wrong column. Steps to reproduce: - With a DE Company - Open Accounting / Reporting / Audit Reports / General Ledger - Click "Datev Data (ZIP)" - Open EXTF_accounting_entries.csv According to the documentation https://apps.datev.de/help-center/documents/1003221 Chapter 3. when a journal entry is in a foreign currency: - The amount in foreign currency should go into Column B - The c

In the Datev standard export, sales with foreign currency and currency indicator are exported to the wrong column.

Steps to reproduce:
- With a DE Company
- Open Accounting / Reporting / Audit Reports / General Ledger
- Click "Datev Data (ZIP)"
- Open EXTF_accounting_entries.csv

According to the documentation
https://apps.datev.de/help-center/documents/1003221 Chapter 3. when a journal entry is in a foreign currency:

- The amount in foreign currency should go into Column B
- The currency code should go into Column C
- The base currency amount (i.e. the company's local currency) should be shown in Columns E and F

opw-4701001

Forward-Port-Of: odoo/enterprise#87416
Forward-Port-Of: odoo/enterprise#87002

Currently a traceback is occurring when the user tries to create a Draft Entry, in the batch that contains payslips of multiple companies. **To reproduce this issue:** 1) Install hr_payroll_account and switch to multi-company environment 2) Create two employees with two running contracts respectively 3) Now create a Batch record from payroll/payslips/batches 4) Create two playslips with different companies with the created batch 5) Compute both the payslips and open the batch 6)

Currently a traceback is occurring when the user tries to create a Draft Entry, 
in the batch that contains payslips of multiple companies.

**To reproduce this issue:**

1) Install hr_payroll_account and switch to multi-company environment 
2) Create two employees with two running contracts respectively 
3) Now create a Batch record from payroll/payslips/batches 
4) Create two playslips with different companies with the created batch 
5) Compute both the payslips and open the batch
6) Now, try to click on the  Create Draft Entry

**Error:**
A traceback will occur.
```
ValueError: Expected singleton: res.company(1, 2)
```

**Cause:**
When the user created multiple payslips with multiple companies containing the same batch 
and tries to create a Draft Entry, we filtered out the payslips based on the payslip state, 
and try to change the state to Done using the action_payslip_done method.

https://github.com/odoo/enterprise/blob/1e5d7155466f80942f0b8fe2df7fdfb86cae7417/hr_payroll/models/hr_payslip_run.py#L70

So the self will contain multiple payslip recordsets with different company in each payslip. 
This leads to the above traceback when accessing company_id from self
https://github.com/odoo/enterprise/blob/1e5d7155466f80942f0b8fe2df7fdfb86cae7417/hr_payroll_account/models/hr_payslip.py#L61

**Solution:**

In payslips, the company_id field should be in readonly state, 
since the value of the company_id will  computed from the employee_id which is a required field.

Also raised a validation Error for the previously created record to handle the traceback.

Related Upgrade PR:- https://github.com/odoo/upgrade/pull/7763

opw-4797089

Forward-Port-Of: odoo/enterprise#87306
Forward-Port-Of: odoo/enterprise#86628

After this commit https://github.com/odoo/enterprise/pull/74528/commits/c0af404c2b3e08ec92243f4c070f915833b4a538 some tests are failing when we don't have timesheet_grid module installed as the allocated hours will get recomputed so the behavior will be different. To fix this we moved all of the tests that test allocated hours value to timesheet_grid and adapted another test to check whether we have the timesheet_grid module installed or not and upon this check we change the value that we are

After this commit https://github.com/odoo/enterprise/pull/74528/commits/c0af404c2b3e08ec92243f4c070f915833b4a538 some tests are failing when we don't have timesheet_grid module installed as the allocated hours will get recomputed so the behavior will be different.

To fix this we moved all of the tests that test allocated hours value to timesheet_grid and adapted another test to check whether we have the timesheet_grid module installed or not and upon this check we change the value that we are checking.

runbot-115003

Forward-Port-Of: odoo/enterprise#81643