Task Adhoc side: 34375 Task Latam side: 1177 Modify "help" attribute of l10n_ar_special_purchase_document_type_ids (Other Purchase Documents) field on model res.partner to tell that it will be deprecated on next version. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162812

Task Adhoc side: 34375
Task Latam side: 1177
Modify "help" attribute of l10n_ar_special_purchase_document_type_ids (Other Purchase Documents) field on model res.partner to tell that it will be deprecated on next version.

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

Forward-Port-Of: odoo/odoo#162812

…ds) account move line text, based on pos orders **Description of the issue/feature this PR addresses:** During the close of the PoS session, account move are generated. the text of the lines depends on the sales (and refund). for the time being, some part of text are not translatable. **Current behavior before PR:**  **Desired behavior after PR is merged:** Text can be translated. + fre

…ds) account move line text, based on pos orders

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

During the close of the PoS session, account move are generated. the text of the lines depends on the sales (and refund). for the time being, some part of text are not translatable.

**Current behavior before PR:**

![image](https://github.com/user-attachments/assets/f6745f54-ee75-4fc8-9070-4e1c65eba709)


**Desired behavior after PR is merged:**

Text can be translated.
+ french translation added.



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

Forward-Port-Of: odoo/odoo#174647
Forward-Port-Of: odoo/odoo#174511

Pension Fund tax was incorrectly applied at the invoice level instead of the line level. When importing it as a vendor bill, this caused incorrect amounts due to the tax being applied to all lines. This commit exports TipoDato = "AswCassPre" for lines with the pension fund applied. During XML import, it checks which lines should have the "pension fund" tax and applies it accordingly. task-3969730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Pension Fund tax was incorrectly applied at the invoice level instead of the line level. When importing it as a vendor bill, this caused incorrect amounts due to the tax being applied to all lines.

This commit exports TipoDato = "AswCassPre" for lines with the pension fund applied. During XML import, it checks which lines should have the "pension fund" tax and applies it accordingly.

task-3969730

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

Forward-Port-Of: odoo/odoo#170012

This commit does three things: 1) Global Discounts: When creating an invoice with a negative line, such as a Tax Invoice with global discount, we process the line as a document level allowance as required by ZATCA, and remove it from the lines sent in the UBL. This allows us to provide support for global discounts, such as those applied by promotion programs 2) Add support for down-payment document type in _l10n_sa_get_invoice_type method: 386 3) Trim spaces from phone numbers b

This commit does three things:
    
1) Global Discounts: When creating an invoice with a negative line, such as a Tax Invoice with global discount, we process the line as a document level allowance as required by ZATCA, and remove it from the lines sent in the UBL. This allows us to provide support for global discounts, such as those applied by promotion programs

2) Add support for down-payment document type in _l10n_sa_get_invoice_type method: 386
    
3) Trim spaces from phone numbers before submission to avoid receiving warnings from ZATCA

Description of the issue/feature this PR addresses:
Process global discounts into AllowanceCharge values for ZATCA saudi eInvoicing.
Avoid warnings regarding spaces in phone numbers.
Add support for down-payment invoice type code.

Current behavior before PR:
If a promotions program is applied on a sale order or POS order, or a line with a negative amount is added on an invoice, the line is sent as is to the authorities, which triggers an error as ZATCA only accepts positive amount lines.
If a phone number is provided, ZATCA returns a warning regarding the phone number format.

Desired behavior after PR is merged:
Negative lines on an invoice, that are not related to a down-payment, should be processed as document level allowances.
Phone numbers are correctly formatted prior to sending to ZATCA.
Down-payment invoices use the appropriate document type code.



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

Forward-Port-Of: odoo/odoo#154608
Forward-Port-Of: odoo/odoo#153379

Currently when importing an order from sale to pos, if the price was set manually, changing the partner associated with the order will set back the price to the original product sale price. Steps to reproduce: ------------------- * Make a new quotation in **sales** * Change the unit price of a product * Confirm quotation * Open the pos shop session * Import the newly created quotation to be settled * Change the partner > Observation: The price set manually changes to the product sale

Currently when importing an order from sale to pos, if the price was set manually, changing the partner associated with the order will set back the price to the original product sale price.

Steps to reproduce:
-------------------
* Make a new quotation in **sales**
* Change the unit price of a product
* Confirm quotation
* Open the pos shop session
* Import the newly created quotation to be settled
* Change the partner
> Observation: The price set manually changes to the product sale price

Why the fix:
------------
When changing the partner of a sale order we compute all the line that have to recompute their prices:
https://github.com/odoo/odoo/blob/57f1b0bd502938a6d50244896e71df73705584b5/addons/point_of_sale/static/src/js/models.js#L2918-L2920

We see that when we settle an order, `price_manually_set` is set to false. In this example, if we set it to true it would solve the issue but we cannot use it, see with https://github.com/odoo/odoo/commit/70668ee3c3e2c1dd213903b44f4d36cc8ac9fa29 .

Instead what we can do is to use `price_automatically_set` and set it to true. This does not undo the previously mentionned commit and fixes this current issue. This variable was created in https://github.com/odoo/odoo/commit/067299539116b55a449f022706c395dda2177829

opw-4001497

Forward-Port-Of: odoo/odoo#174649
Forward-Port-Of: odoo/odoo#172205

`odoo` alias on IoTBox is meant to start Odoo with cli. It used to restart the service before starting by cli, causing a `address already in use` error. Replaced `restart` by `stop` to avoid restarting the service. Forward-Port-Of: odoo/odoo#174619

`odoo` alias on IoTBox is meant to start Odoo with cli. It used to restart the service before starting by cli, causing a `address already in use` error. Replaced `restart` by `stop` to avoid restarting the service.

Forward-Port-Of: odoo/odoo#174619

This PR bugfix an error: "Error: Finalized Order cannot be modified" during a pos session. Steps to reproduce: 1. Install `pos_loyalty` module 2. Use any loyalty program (in video I used a gift card) on a pos order 3. Paid order but stay on "ReceiptScreen" 4. Click on "Orders" ("TicketButton") 5. Click on "New Order" 6. Click again on "Orders" and select paid order in status "Receipt" 7. "Error: Finalized Order cannot be modified" is shown Video of steps: https://www.loom.com/sha

This PR bugfix an error: "Error: Finalized Order cannot be modified" during a pos session.

Steps to reproduce:

1. Install `pos_loyalty` module
2. Use any loyalty program (in video I used a gift card) on a pos order
3.  Paid order but stay on "ReceiptScreen"
4. Click on "Orders" ("TicketButton")
5. Click on "New Order"
6. Click again on "Orders" and select paid order in status "Receipt"
7. "Error: Finalized Order cannot be modified" is shown

Video of steps: https://www.loom.com/share/6ea8c86ebd994ce0958f42b6eb12c5db

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

Forward-Port-Of: odoo/odoo#172582
Forward-Port-Of: odoo/odoo#168142

In this commit https://github.com/odoo/odoo/pull/157503/commits/98368c363bf4cb9604948a52196c6a61985dc34d we added the bank account (if present) next to the communication printed on the invoice. This commit apply the same logic to the "send and print" template task: 4048178 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174549 Forward-Port-Of: odoo/odoo#172775

In this commit https://github.com/odoo/odoo/pull/157503/commits/98368c363bf4cb9604948a52196c6a61985dc34d we added the bank account (if present) next to the communication printed on the invoice.

This commit apply the same logic to the "send and print" template

task: 4048178




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

Forward-Port-Of: odoo/odoo#174549
Forward-Port-Of: odoo/odoo#172775

Currently the logs are being spammed with warning messages which shouldn't be warnings as it's a normal behavior 1) When no database is connected we log "warning invalid ssl certificate" 2) When no database is connected we log "warning odoo server not set" I log both as info level to still keep this information but avoid spamming useful error logs with it Forward-Port-Of: odoo/odoo#174702

Currently the logs are being spammed with warning messages which shouldn't be warnings as it's a normal behavior

1) When no database is connected we log "warning invalid ssl
   certificate"
2) When no database is connected we log "warning odoo server not set"

I log both as info level to still keep this information but avoid spamming useful error logs with it

Forward-Port-Of: odoo/odoo#174702

**Steps to reproduce:** - Install l10n_ar and website_sale - Switch to an Argentinian company - Create a product with a customer tax (e.g. IVA 21%) With a public user or a user without "AFIP Responsibility": - Go to eShop and add the created product to the cart - Go to the cart **Issue:** No tax is applied. **Cause:** There are some fiscal positions from Argentinian localization that map IVA 21% to IVA Exento (i.e. 0%). These fiscal positions are linked to specific "AFIP Respons

**Steps to reproduce:**
- Install l10n_ar and website_sale
- Switch to an Argentinian company
- Create a product with a customer tax (e.g. IVA 21%)

With a public user or a user without "AFIP Responsibility":
- Go to eShop and add the created product to the cart
- Go to the cart

**Issue:**
No tax is applied.

**Cause:**
There are some fiscal positions from Argentinian localization that map IVA 21% to IVA Exento (i.e. 0%).
These fiscal positions are linked to specific "AFIP Responsibility" types and should only be applied for users having these "AFIP Responsibility" types configured on their contact form.
However, when this field is not set, it is ignored in the domain computing the fiscal position and one of these Argentinian fiscal positions satisfies the resulting domain.

**Solution:**
Filter on "AFIP Responsibility" in the domain computing the fiscal position if "l10n_ar_afip_responsibility_type_id" key is present in the context, no matter what its value.

opw-3943108




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

Forward-Port-Of: odoo/odoo#171923

Specification: The ribbon overlaps with the dropdown menu.  Expected behavior: The ribbon should not overlap with the dropdown menu. Task-3940927 Forward-Port-Of: odoo/odoo#172102

Specification:
The ribbon overlaps with the dropdown menu.

![image](https://github.com/odoo/odoo/assets/120459800/0aa2c2e0-2d62-4413-94d8-134828511c0e)


Expected behavior:
The ribbon should not overlap with the dropdown menu.

Task-3940927

Forward-Port-Of: odoo/odoo#172102

Steps to reproduce: - Create a product with MTO & Buy routes. - Define a vendor for the product. - Create a sale order for this product. - Go to the related purchase order and confirm it. - Decrease the quantity of the PO line. - Go to the related receipt picking. (Do the above steps or any action that leads to logging an activity that has links to records). Expected behavior: Clicking on the record names in the logged exception redirects to these records. Current behavior: Not

Steps to reproduce:
- Create a product with MTO & Buy routes.
- Define a vendor for the product.
- Create a sale order for this product.
- Go to the related purchase order and confirm it.
- Decrease the quantity of the PO line.
- Go to the related receipt picking.
 
(Do the above steps or any action that leads to logging an activity that has links to records).

Expected behavior:
Clicking on the record names in the logged exception redirects to these records.

Current behavior:
Nothing happens.

opw-4045174

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

Forward-Port-Of: odoo/odoo#174907
Forward-Port-Of: odoo/odoo#174497

In this PR: https://github.com/odoo/odoo/pull/172760 the check_vat_il function is calling `self.company`. It appears it was not a good idea and several things were not done well: - It could lead to errors as run_vat_test can be called on multiple partners: https://github.com/odoo/odoo/blob/16.0/addons/base_vat/models/res_partner.py#L170. - The previous PR is also checking the VAT number depending on the field is_company but did not put it as a constraint. This can be fixed, but with more ch

In this PR: https://github.com/odoo/odoo/pull/172760 the check_vat_il function is calling `self.company`.

It appears it was not a good idea and several things were not done well:
- It could lead to errors as run_vat_test can be called on multiple partners: https://github.com/odoo/odoo/blob/16.0/addons/base_vat/models/res_partner.py#L170.
- The previous PR is also checking the VAT number depending on the field is_company but did not put it as a constraint. This can be fixed, but with more changes than needed.

It has been decided to use the `idnr` check for all Israeli VAT numbers, regardless of the partner type. With this change the VAT check for companies is not complete: it is not tested that they begin by a 5. But it is good enough.

opw-3954674

Forward-Port-Of: odoo/odoo#174817

This commit modifies the AddInternalNotes tour method to support empty internal note. Related enterprise PR: https://github.com/odoo/enterprise/pull/66145 sentry-5494183916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174107 Forward-Port-Of: odoo/odoo#172730

This commit modifies the AddInternalNotes tour method to support 
empty internal note.

Related enterprise PR: https://github.com/odoo/enterprise/pull/66145

sentry-5494183916

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

Forward-Port-Of: odoo/odoo#174107
Forward-Port-Of: odoo/odoo#172730

Since we are using an existing record as `mail_message_id` in `_notify_thread_by_email`, and we need to allow the creation of new `mail.mail` that will add new values to the `mail.message`, as long as it doesn't modify existing values. We are already writing on `subject` only if it was different than previously, but we are not forbidding to write on it only if there was a previous value set. Forward-Port-Of: odoo/odoo#173366

Since we are using an existing record as `mail_message_id` in `_notify_thread_by_email`, and we need to allow the creation of new `mail.mail` that will add new values to the `mail.message`, as long as it doesn't modify existing values.
We are already writing on `subject` only if it was different than previously, but we are not forbidding to write on it only if there was a previous value set.

Forward-Port-Of: odoo/odoo#173366

Problem: For a gift card with 0 points which have its price changed a popup error is displayed saying the gift card has already been sold Steps to reproduce: - Install "point_of_sale" app and "pos_loyalty" module - Select "Scan existing cards" in the promotions settings - Generate a gift card with a value of 0.00 $ and copy its code - Start a shop session - Select the gift card product and enter the code - Change the price of the gift card (must be an integer < 10) - Proceed to the pa

Problem:
For a gift card with 0 points which have its price changed a popup error is displayed saying the gift card has already been sold

Steps to reproduce:
- Install "point_of_sale" app and "pos_loyalty" module
- Select "Scan existing cards" in the promotions settings
- Generate a gift card with a value of 0.00 $ and copy its code
- Start a shop session
- Select the gift card product and enter the code
- Change the price of the gift card (must be an integer < 10)
- Proceed to the payment
- See the popup error

Cause:
As the gift card has no points, `couponPointChanges` stays empty. But when the price is modified, `couponPointChanges` is updated but has no giftCardId so the error is triggered (see `validateOrder` in PaymentScreen.js). There is no issue if the price is > 10 or is not an integer because `_updatePrograms` is called after each click on the numpad and `changesPerProgram` gets the values of `couponPointChanges` which are the saved in `oldChanges` which is modified by getting the values of `pointsAdded` which has `giftCardId` so `couponPointChanges` get the `giftCardId`

opw-3909019


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

Forward-Port-Of: odoo/odoo#174982
Forward-Port-Of: odoo/odoo#174538

When exporting fec file, data from child companies should be included in the file. opw-4014583 Forward-Port-Of: odoo/odoo#174572

When exporting fec file, data from child companies
should be included in the file.

opw-4014583

Forward-Port-Of: odoo/odoo#174572

Prior to this commit, performing a search in the PoS and selecting "Search more" would load products not belonging to the restricted categories. opw-4061359 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174729 Forward-Port-Of: odoo/odoo#173885

Prior to this commit, performing a search in the PoS and selecting "Search more" would load products not belonging to the restricted categories.

opw-4061359

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

Forward-Port-Of: odoo/odoo#174729
Forward-Port-Of: odoo/odoo#173885

In list views, the label of a field, displayed in the thead, is sometimes truncated (especially as we apply our own column widths logic). Moreover, fields might sometimes be unclear to the user, and in the list view we don't benefit from the "help" that might be defined on the field. This commit helps with those two issues. In non debug mode, there's now a tooltip on the field's label. This tooltip contains the (never truncated) label and the help when there's one. Note that in debug, noth

In list views, the label of a field, displayed in the thead, is sometimes truncated (especially as we apply our own column widths logic). Moreover, fields might sometimes be unclear to the user, and in the list view we don't benefit from the "help" that might be defined on the field.

This commit helps with those two issues. In non debug mode, there's now a tooltip on the field's label. This tooltip contains the (never truncated) label and the help when there's one.

Note that in debug, nothing changes: we still display a big tooltip with a lot more information.

task 4049882

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#175020
Forward-Port-Of: odoo/odoo#173178

When a tax ID is displayed on a report, pingen is failing because the tax ID is rendered in pingen's postable area. This commit adds a margin after the address to ensure nothing disturbs the address area for pingen. Target 17 -> 17.4, to be adapted for master in https://github.com/odoo/odoo/pull/174635 . task-4080193 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174830

When a tax ID is displayed on a report, pingen is failing because the tax ID is rendered in pingen's postable area.

This commit adds a margin after the address to ensure nothing disturbs the address area for pingen.

Target 17 -> 17.4, to be adapted for master in https://github.com/odoo/odoo/pull/174635 .

task-4080193


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

Forward-Port-Of: odoo/odoo#174830

Currently, when buying a gift card through the website and choosing the options to pick up in store and pay in store, the quantity set when settling the order is zero. Steps to reproduce (initial): ----------------------------- * Go to the **website** app * Select **configuration** > **Payment Providers** * Make sure `Pay in store` is published and enabled/or in test mode * Select **configuration** > **Shipping methods** * Make sure that a shipping method `Pick in store` is set up and p

Currently, when buying a gift card through the website and choosing the options to pick up in store and pay in store, the quantity set when settling the order is zero.

Steps to reproduce (initial):
-----------------------------
* Go to the **website** app
* Select **configuration** > **Payment Providers**
* Make sure `Pay in store` is published and enabled/or in test mode
* Select **configuration** > **Shipping methods**
* Make sure that a shipping method `Pick in store` is set up and published for your shop
* Now make an order on the website for a gift card and any storable product
* Choose the options to pick and pay in store
* Go to the **Point of sale** app
* Open shop session
* Settle the order just created
> Observation: The quantity for the gift card is 0

Steps to reproduce (alternative):
---------------------------------
* Go to **Sale** App
* Create a quotation for a gift card and any storable product
* Save the quotation (not confirm)
* Go to the **Point of sale** app
* Open shop session
* Settle the order just created

Why the fix:
------------
The issue is not specific to the gift card product, it affects all `'service'` products.
https://github.com/odoo/odoo/blob/7be2770f2a8dc26f7aa0c539b878b258e94592c8/addons/pos_sale/static/src/js/models.js#L85-L91

We notice that, if the order was paid instead of choosing the option to pay in store, the quantity on the pos order when settling it is 1. This is because the order not yet paid is still considered as a quotation. While if it is paid through the website it is considered as a sale order and thus `qty_to_invoice` has been computed.

The same behaviors can be replicated through the **Sale** app. If a quotation is only saved we also have a quantity of 0. If it is confirmed, the quantity is 1.

As discussed with DALA, using `qty_to_invoice` to set up the quantity in POS only makes sense when we deal with sale orders. When dealing with quotations we should set the quantities in the shop order depending on the quantities of the quotation.

opw-4003749

Forward-Port-Of: odoo/odoo#175000
Forward-Port-Of: odoo/odoo#173146

Steps to reproduce: - Set delivery in 2 steps - Create a sales - Validate the transfer from Stock to Output. The delivery status changes from "not delivered" to "partially delivered" even though nothing has been delivered to the customer. After the fix: If a picking is validated but nothing was delivered to the customer yet, the delivery status is set to "Started". OPW-3948025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-

Steps to reproduce:
- Set delivery in 2 steps
- Create a sales
- Validate the transfer from Stock to Output.
The delivery status changes from "not delivered" to "partially delivered" even though nothing has been delivered to the customer.

After the fix:
If a picking is validated but nothing was delivered to the customer yet, the delivery status is set to "Started".


OPW-3948025

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

Forward-Port-Of: odoo/odoo#174986
Forward-Port-Of: odoo/odoo#169194

Steps to reproduce ================== In 17.2: - Install calendar,hr_homeworking - Use the emulated mobile view from the devtools - Go to calendar - Swipe horizontally to change the displayed week => A crash occurs here https://github.com/odoo/odoo/blob/saas-17.2/addons/hr_homeworking/static/src/calendar/common/calendar_common_renderer.js#L108 Cause of the issue ================== The `AttendeeCalendarCommonRenderer` is rendered before the data for the next week has been loa

Steps to reproduce
==================

In 17.2:
- Install calendar,hr_homeworking
- Use the emulated mobile view from the devtools
- Go to calendar
- Swipe horizontally to change the displayed week

=> A crash occurs here

https://github.com/odoo/odoo/blob/saas-17.2/addons/hr_homeworking/static/src/calendar/common/calendar_common_renderer.js#L108

Cause of the issue
==================

The `AttendeeCalendarCommonRenderer` is rendered before the data for the next week has been loaded.

This means that `this.props.model.worklocations` has no entry for the `parsedDate`.

Solution
========

Await the action before modifying the ActionSwiper state

opw-4047632

Forward-Port-Of: odoo/odoo#174825
Forward-Port-Of: odoo/odoo#173305

If there is a user that sends and/or receives lots of Peppol messages, we send a request to fetch documents/messages for all of them at once. This can result in low performance or memory errors. It is better to batch messages into a reasonable number of messages. no task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175057 Forward-Port-Of: odoo/odoo#175003

If there is a user that sends and/or receives lots of Peppol messages, we send a request to fetch documents/messages for all of them at once.

This can result in low performance or memory errors. It is better to batch messages into a reasonable number of messages.

no task



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

Forward-Port-Of: odoo/odoo#175057
Forward-Port-Of: odoo/odoo#175003

Payment method configuration now uses a clearer “none” value for refund support instead of the confusing “empty” label. This makes refund capabilities easier for users and administrators to understand when configuring online sales payments.

-> This commit improves the clarity and usability of the payment method
configurations, specifically focusing on refund options.

Before this commit:
-> The type of refund supported was 'empty' which led to confusion.

After this commit:
-> Replace the support_refund field to 'none' from 'empty'
which make more intuitive for users.

Check the community PR for more details.

task-3974054

See also:
- https://github.com/odoo/odoo/pull/169473
- https://github.com/odoo/upgrade/pull/6162