This commit https://github.com/odoo/enterprise/pull/67520/commits/ed431cd78dea4ad40e0e6a82eb3ffd9f44026d71 adds `move_type = entry` on the `3.1 a,b,c,e` report lines, but only `misc` entries coming from the POS should impact the line. PoS entries are also considered in section 4, but they shouldn't. To determine which moves are from the PoS we use the l10n_in_pos_session_ids field from module l10n_in_reports_gstr_pos, so we had to inherit the report in that module to add the condition. [Ta

This commit https://github.com/odoo/enterprise/pull/67520/commits/ed431cd78dea4ad40e0e6a82eb3ffd9f44026d71 adds `move_type = entry` on the `3.1 a,b,c,e` report lines, but only `misc` entries coming from the POS should impact the line. PoS entries are also considered in section 4, but they shouldn't.

To determine which moves are from the PoS we use the l10n_in_pos_session_ids field from module l10n_in_reports_gstr_pos, so we had to inherit the report in that module to add the condition.

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

Forward-Port-Of: odoo/enterprise#71315

* test_whatsapp odoo/odoo#178173 Forward-Port-Of: odoo/enterprise#69056

* test_whatsapp

odoo/odoo#178173

Forward-Port-Of: odoo/enterprise#69056

Consider an unreconciled bank statement (line) in the bank reconciliation widget. Currently only the liquidity and suspense/transfer line of the associated move are shown. This means that some lines of the move are not shown. After this commit we show all the line (so i.e. the other lines). Since the diff is not the nicest: The commit just removes the outer `if wizard.st_line_id.is_reconciled`. Forward-Port-Of: odoo/enterprise#71504 Forward-Port-Of: odoo/enterprise#71236

Consider an unreconciled bank statement (line) in the bank reconciliation widget.
Currently only the liquidity and suspense/transfer line of the associated move are shown.
This means that some lines of the move are not shown.

After this commit we show all the line (so i.e. the other lines).

Since the diff is not the nicest:
The commit just removes the outer `if wizard.st_line_id.is_reconciled`.

Forward-Port-Of: odoo/enterprise#71504
Forward-Port-Of: odoo/enterprise#71236

In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye. So, its name needed to be changed in its Odoo modules. Moreover, updated Turkish modules descriptions according to this excalidraw: https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true task-4182931 Forward-Port-Of: odoo/enterprise#71444 Forward-Port-Of: odoo/enterprise#70304

In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye.
So, its name needed to be changed in its Odoo modules.
Moreover, updated Turkish modules descriptions according to this excalidraw:
https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true

task-4182931

Forward-Port-Of: odoo/enterprise#71444
Forward-Port-Of: odoo/enterprise#70304

**[FIX] l10n_uy_edi: Do not check latam document number** When an invoice sent to DGI returns errors (e.g., wrong partner or other data issues), users can reset it to draft and make corrections. However, changing the partner triggers a validation error because the invoice lacks a valid latam document number (only provided by DGI after processing). To avoid this, resetting the invoice to draft clears the invoice name, allowing users to fix any errors without triggering the validation. **

**[FIX] l10n_uy_edi: Do not check latam document number**  
  When an invoice sent to DGI returns errors (e.g., wrong partner or other data issues), users can reset it to draft and make corrections. However, changing the partner triggers a validation error because the invoice lacks a valid latam document number (only provided by DGI after processing). To avoid this, resetting the invoice to draft clears the invoice name, allowing users to fix any errors without triggering the validation. 

**[FIX] l10n_uy_edi: Create Uruware account help**  
  Improved the helper to remove "admin email" (since it no longer applies) and updated translations accordingly.

**[FIX] l10n_uy_edi: Send and Print after Post**  
  Fixed an issue where the send and print wizard was triggered before the invoice was posted, causing errors. The wizard now only runs after the invoice has been successfully posted.

Forward-Port-Of: odoo/enterprise#70351

Commit 1 ======== Steps to reproduce the issue: - add comment to a Facebook/youtube post. - keeping the `Comments` dialog box open, try replying the same comment. - we get a traceback. Reason: - due to the missing comments data structure, we get an error when trying to add the new comment. - LOC responsible for the traceback: https://github.com/odoo/enterprise/blob/16.0/social/static/src/xml/social_templates.xml#L311 Fix: - since the comments data structure is not returned from t

Commit 1
========

Steps to reproduce the issue:
- add comment to a Facebook/youtube post.
- keeping the `Comments` dialog box open, try replying the same comment.
- we get a traceback.

Reason:
- due to the missing comments data structure, we get an error when trying to add the new comment.
- LOC responsible for the traceback: https://github.com/odoo/enterprise/blob/16.0/social/static/src/xml/social_templates.xml#L311

Fix:
- since the comments data structure is not returned from the post request made to post the commnet, we manually ensure it exists.

Commit 2
========

[FIX] social: fix various issues
1. social_instagram:

ISSUES:
- create a post on the instagram platform with commenting turned off.
- try commenting on it from Odoo. We get a traceback.
- also, if we delete the post from the platform and then try to comment from Odoo,
  we get a traceback.

REASON:
- there is no existing implementation to check if commenting is enabled/disabled
  on the post.

FIX:
- we now check if commenting is enabled or not while trying to add comment on the post

TECHNICAL NOTE:
- the correct way to check if commenting on a post is enabled or not is to request
  a field named `is_comment_enabled`.
- more details --- https://developers.facebook.com/docs/instagram-platform/instagram-graph-api/reference/ig-media
- but to save us from making an extra request, we simply catch the error received to
  when trying to add a comment.

================================================================================

2. social_linkedin

ISSUE:
- delete an existing post from the linkedIn platform.
- now try commenting on it from Odoo. We get a traceback.

REASON:
- The response received from the request to fetch the comments is not validated.

FIX:
- validating the response before further execution.

Task-3759530

Forward-Port-Of: odoo/enterprise#71428
Forward-Port-Of: odoo/enterprise#67079

- In order to have more detail of the product used in the invoice, many companies place information in the label of the invoice line, we prioritize the name field to be displayed in the description tag of the xml. Forward-Port-Of: odoo/enterprise#70694

- In order to have more detail of the product used in the invoice, many companies place information in the label of the invoice line, we prioritize the name field to be displayed in the description tag of the xml.

Forward-Port-Of: odoo/enterprise#70694

According to the documentation of the new Modelo 303 BOE export, the new fields that will be used for the declarations starting in 10/2024 or Q4/2024 "can only be completed from periods 10 and 4Q of 2024 and subsequent years". As such, we left the fields "empty" using the space character (like in other places). However, now that the new AEAT submission page is ready, it seems they expect us to fill the new fields with zeroes instead of leaving them empty. This commit fixes that. [opw-4222842](

According to the documentation of the new Modelo 303 BOE export, the new fields that will be used for the declarations starting in 10/2024 or Q4/2024 "can only be completed from periods 10 and 4Q of 2024 and subsequent years". As such, we left the fields "empty" using the space character (like in other places).

However, now that the new AEAT submission page is ready, it seems they expect us to fill the new fields with zeroes instead of leaving them empty. This commit fixes that.

[opw-4222842](https://www.odoo.com/odoo/all-tasks/4222842)

Forward-Port-Of: odoo/enterprise#71407
Forward-Port-Of: odoo/enterprise#71379

Method `action_post()` was added in 17.0 as a front-end helper funcion to initialize `_post()`. This method is expected to return a value, however, `action_post()` was missing the intended `return` statement. This causes external API calls to `action_post()` to fail since `_xmlrpc()` does not allow `NoneType` values. To reproduce: 1) Create an invoice using external API. 2) Attempt a call to action_post() using xmlrpc. 3) TypeError("cannot marshal None unless allow_none is enabled") should

Method `action_post()` was added in 17.0 as a front-end helper funcion to initialize `_post()`. This method is expected to return a value, however, `action_post()` was missing the intended `return` statement. This causes external API calls to `action_post()` to fail since `_xmlrpc()` does not allow `NoneType` values.

To reproduce:
1) Create an invoice using external API.
2) Attempt a call to action_post() using xmlrpc.
3) TypeError("cannot marshal None unless allow_none is enabled") should appear.

Forward-Port-Of: odoo/enterprise#71324

**Current behavior:** If you have a production opened in barcode and consume part of a component line to produce part of the final product, leave the transfer, then re-open it and confirm -> create the backorder, the resulting backorder will have split the remaining raw moves in an unintuitive manner. **Expected behavior:** The backorder should have one move for the remaining component quantity. **Steps to reproduce:** 1. Create a production for 10 of some final product consuming 1

**Current behavior:**
If you have a production opened in barcode and consume part of a
component line to produce part of the final product, leave the
transfer, then re-open it and confirm -> create the backorder,
the resulting backorder will have split the remaining raw moves
in an unintuitive manner.

**Expected behavior:**
The backorder should have one move for the remaining component
quantity.

**Steps to reproduce:**
1. Create a production for 10 of some final product consuming 10
     some component -> Confirm

2. Open the production in barcode, add 5 of the final product to
     its line and 5 of the component to its line -> exit the
     transfer view

3. Reopen the production and validate it -> create backorder

4. Open the backorder to see the odd split of the component
     product's moves

**Cause of the issue:**
When creating the backorder we normally expect each component
product to be encapsulated by a single line- so the split that
occurs when we leave the transfer initially without validating
which creates 2 moves for the same product means we get 2 moves
for the component for half of the remaining quantity for that
component.

**Fix:**
Incomplete barcode lines for production transfers should get
split into additional move lines as opposed to moves.

opw-4148050

Forward-Port-Of: odoo/enterprise#69149

Steps to reproduce: - Create a product with the following settings: -- Product Type: Service; Invoicing Policy: Based on Timesheets -- Create on Order: Project & Task; Unit of Measure: Days -- Sales Price: 120 (Use != 100 when using Mitchel Admin) - Create a quotation for this product and confirm it - Created Task > Timesheets tab > Record 4 hours - Go to Planning > New > Create a 1 day shift for Mitchel Admin - Link that shift to the project created by your SO - Enable 'Project Planning'

Steps to reproduce:
- Create a product with the following settings: -- Product Type: Service; Invoicing Policy: Based on Timesheets -- Create on Order: Project & Task; Unit of Measure: Days -- Sales Price: 120 (Use != 100 when using Mitchel Admin)
- Create a quotation for this product and confirm it
- Created Task > Timesheets tab > Record 4 hours
- Go to Planning > New > Create a 1 day shift for Mitchel Admin
- Link that shift to the project created by your SO
- Enable 'Project Planning' in Settings > Planning
- Go to Project > : Menu > 'Timesheet and planning analysis'
- Under the Measures dropdown, add all columns

You will notice that the measures for revenue and margin are computed as though the unit price corresponds to 1h even though our product uom is Days. This makes the computations for revenues and margins completely wrong. This happens because the module converts all values into hours without accounting for the fact that the SOL unit price is not necessarily by the hour. This happens regardless of the 'Encoding Method' setting of Timesheet.

opw-3918082

Forward-Port-Of: odoo/enterprise#71425

**Steps to reproduce:** - Install Invoicing, l10n_eu_oss and l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice for a Portugese customer: * Customer: [a Portugese customer] * Invoice Lines: [a line with OSS tax "23.0% PT VAT (Goods)"] - Make sure that "Tax Type (Spain)" of the tax is set to "No Sujeto por reglas de Localization" - Confirm the invoice - Process the invoice by E-invoicing service: TicketBAI (ES) - Check the generated EDI document *

**Steps to reproduce:**
- Install Invoicing, l10n_eu_oss and l10n_es_edi_tbai
- Switch to a Spanish company (e.g. ES Company)
- Create an invoice for a Portugese customer:
  * Customer: [a Portugese customer]
  * Invoice Lines: [a line with OSS tax "23.0% PT VAT (Goods)"]
- Make sure that "Tax Type (Spain)" of the tax is set to "No Sujeto por reglas de Localization"
- Confirm the invoice
- Process the invoice by E-invoicing service: TicketBAI (ES)
- Check the generated EDI document

**Issue:**
The value of "Causa" in "NoSujeta" section is "RL". It should be "IE" for OSS taxes.

opw-4034659




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

Forward-Port-Of: odoo/odoo#182730
Forward-Port-Of: odoo/odoo#179289

Steps to reproduce : ==== - Install pos_sale module. - Create a quotation in sales and confirm it. - Open Point of Sale - Open Session and load orders from session. - Select the quotation and do 50% down payment. - Create new order and again load the same quotation. - Due balance remains same. Issue: ==== - Due balance is not updated, everytime it shows total amount. Fix : ==== - Instead of total amount , amount unpaid is displayed which show correct due balance. task- 42040

Steps to reproduce :
====
- Install pos_sale module.
- Create a quotation in sales and confirm it.
- Open Point of Sale
- Open Session and load orders from session.
- Select the quotation and do 50% down payment.
- Create new order and again load the same quotation.
- Due balance remains same.

Issue:
====
- Due balance is not updated, everytime it shows total amount.

Fix :
====
- Instead of total amount , amount unpaid is displayed which show correct due balance.

task- 4204048

Forward-Port-Of: odoo/odoo#181809

Lots of contact information has been changed and some banks has been sold their bisiness portfolio over the years. In some cases the telephone and email links were in the wrong order. Some of the banks were merged or under Sanctions. (Sberbank, IC, MKB, Budapest, Commerz, FHB... ) Original credits to `kerteszgergo`: odoo/odoo#108301 Forward-Port-Of: odoo/odoo#181547

Lots of contact information has been changed and some banks has been sold their bisiness portfolio over the years. In some cases the telephone and email links were in the wrong order.

Some of the banks were merged or under Sanctions. (Sberbank, IC, MKB, Budapest, Commerz, FHB... )

Original credits to `kerteszgergo`: odoo/odoo#108301

Forward-Port-Of: odoo/odoo#181547

**Current behavior:** Changing the cost method of a product's category when that product has a negative on-hand quantity will result in illogical account move's being created during the empty/replenish mechanism which revalues the inventory. Specifically, the stock valuation account will be credited twice, once in each move, the stock input account debited in the emptying move, and the stock output account debited in the replenishing move. **Expected behavior:** The moves and their corre

**Current behavior:**
Changing the cost method of a product's category when that product has a negative on-hand quantity will result in illogical account move's being created during the empty/replenish mechanism which revalues the inventory.

Specifically, the stock valuation account will be credited twice, once in each move, the stock input account debited in the emptying move, and the stock output account debited in the replenishing move.

**Expected behavior:**
The moves and their corresponding lines should be the inverse of those which are generated by this action when the product's on-hand quantity is positive.

**Steps to reproduce:**
1. Enable automatic accounting, create a stored product whose category has `FIFO` costing and `real_time` valuation

2. Create an in move for the product so it gets some cost assigned to it

3. Create an out move for more of the product than is currently in stock (so it's on-hand qty becomes negative)

4. Change the product category's `cost_method` to average/AVCO

5. Observe the journal items created by this action in the accounting application -> see that the stock valuation account is credited in both of the created moves

**Cause of the issue:**
The replenishing move's debiting/crediting accounts are currently adjusted if the associated SVL's quantity is non-positive, but the preceding emptying move's accounts are not. This results in the mismatch.

**Fix:**
Similarly adjust the emptying move accounts as was done to the replenishing move in commit: f7e3ada

opw-4127737

Forward-Port-Of: odoo/odoo#182304

Steps to reproduce: - have two companies A and B - create a new partner - create a new payment term for Company A - In Company A, set the customer's payment term the newly created one - Configure aliases for invoice in company A and B - Make sure the default company for OdooBot is COmpany A - Send an email to company B Issue: Access Error Cause: payment_term is pre-compute and the company context is the one of OdooBot opw-4103229 Forward-Port-Of: odoo/odoo#182181 Forward-Port-

Steps to reproduce:
- have two companies A and B
- create a new partner
- create a new payment term for Company A
- In Company A, set the customer's payment term the newly created one
- Configure aliases for invoice in company A and B
- Make sure the default company for OdooBot is COmpany A
- Send an email to company B

Issue:
Access Error

Cause:
payment_term is pre-compute and the company context is the one of OdooBot

opw-4103229

Forward-Port-Of: odoo/odoo#182181
Forward-Port-Of: odoo/odoo#178829

[FIX] website: fix Facebook snippet The goal of this commit is to solve three bugs introduced by [1]. The first one can be observed thanks to the `/website/demo/snippets` page: - Go on the `/website/demo/snippets` page. - Try to enter in edit mode. -> The system never enters in edit mode. The problem is that the Facebook snippet on this page does not have the `href` data attribute. Due to it, the public widget is started without creating `this.resizeObserver`. When the user tries

[FIX] website: fix Facebook snippet
The goal of this commit is to solve three bugs introduced by [1].

The first one can be observed thanks to the `/website/demo/snippets`
page:
- Go on the `/website/demo/snippets` page.
- Try to enter in edit mode.

-> The system never enters in edit mode.

The problem is that the Facebook snippet on this page does not have the
`href` data attribute. Due to it, the public widget is started without
creating `this.resizeObserver`. When the user tries to enter in edit
mode, the `FacebookPageWidget` public widget is destroyed and the system
tries to disconnect `this.resizeObserver`. As it is not defined, the
system fails in the `destroy()` method.

Steps to reproduce the second bug:
- Add an "Image-Text" snippet on the website.
- Add a "Text-Image" snippet under the "Image-Text" one.
- Save and edit.
- Drop a "Facebook" snippet on the "Image-Text" snippet.
- Move the "Facebook" snippet on the "Text-Image" snippet.
- Click on the undo button.

-> Two iframes are on the Facebook snippet.

The problem is that since [1], the editor observer is not deactivated
when removing the iframe in the `destroy()` method of the
`FacebookPageWidget` widget.

Finally, this commit also adds back the `frameborder` and
`allowTransparency` attributes on the iframe (removed due to [1]) and
sets the width and height in the style attribute. Although the
`frameborder` and `allowTransparency` attributes are deprecated, this
commit adds them back in case a potential customization relies on it.

[1]: https://github.com/odoo/odoo/commit/707dd91d1e83342a328e50b5ad38e6ec1064ec25

task-4220972

Forward-Port-Of: odoo/odoo#182810
Forward-Port-Of: odoo/odoo#182134

This commit will change the name of some account group. task:4186654 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180719

This commit will change the name of some account group.

task:4186654




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

Forward-Port-Of: odoo/odoo#180719

The Issue: Before this commit, assigning a URL to the page triggered the write function. Within this function, the get_current_website function returned a different website than the one in the test. As a result, the rest of the code applied to this incorrect website instead of the appropriate one. The Fix: Pass the correct website within the context runbot-54617 Forward-Port-Of: odoo/odoo#177598 Forward-Port-Of: odoo/odoo#176032

The Issue:
Before this commit, assigning a URL to the page triggered the write function. Within this function, the get_current_website function returned a different website than the one in the test. As a result, the rest of the code applied to this incorrect website instead of the appropriate one.

The Fix:
Pass the correct website within the context

runbot-54617

Forward-Port-Of: odoo/odoo#177598
Forward-Port-Of: odoo/odoo#176032

On the IoT box, translations are not supported as there is no language context and no po/pot files. However, there were still some usages of the `_` function which will now log a warning in version 18.0+. In this PR we simply remove the usages of `_`, as it was not translating anyway and removes the warnings. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182767

On the IoT box, translations are not supported as
there is no language context and no po/pot files.
However, there were still some usages of the `_`
function which will now log a warning in version
18.0+.

In this PR we simply remove the usages of `_`, as
it was not translating anyway and removes the
warnings.

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

Forward-Port-Of: odoo/odoo#182767

In #171244, we prevented users from modifying account codes on German CoAs, as part of changes for GoBD compliance. However, when the user exports and re-imports an entire CoA in Excel, `write` is still called on the account code, even if it doesn't change. With this commit, we don't raise if the code doesn't actually change. Back-port of #181234 task-4192627 Forward-Port-Of: odoo/odoo#182821

In #171244, we prevented users from modifying account codes on German CoAs, as part of changes for GoBD compliance.

However, when the user exports and re-imports an entire CoA in Excel, `write` is still called on the account code, even if it doesn't change.

With this commit, we don't raise if the code doesn't actually change.

Back-port of #181234

task-4192627

Forward-Port-Of: odoo/odoo#182821

Commit that introduced the issue https://github.com/odoo/odoo/pull/128108/commits/33a04876cad58f413455bdc406c1ad4c70d73e1b Steps to reproduce the issue: ============================= - Create a new mass mailing - Add cover snippet - Test the email - Background image doesn't appear Origin of the issue: ==================== After the chnage of the mentioned commit, we add a div with a black background filter. It displays correclty in mass_mailing view since it has opacity 0.5 but afte

Commit that introduced the issue https://github.com/odoo/odoo/pull/128108/commits/33a04876cad58f413455bdc406c1ad4c70d73e1b

Steps to reproduce the issue:
=============================
- Create a new mass mailing
- Add cover snippet
- Test the email
- Background image doesn't appear

Origin of the issue:
====================
After the chnage of the mentioned commit, we add a div with a black background filter. It displays correclty in mass_mailing view since it has opacity 0.5 but after the `inline` process of the template we convert rgba colors to hex color with `rgbToHex` because some email engines doesn't support rgba. As a result, we will have a black div that covers the background image in the sent email.

Solution:
=========
Rever the change.

task-4070400

Forward-Port-Of: odoo/odoo#177174

In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye. So, its name needed to be changed in its Odoo modules. Moreover, updated Turkish modules descriptions according to this excalidraw: https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true task-4182931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182743 Forward-Port-Of: odoo/odoo#180758

In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye.
So, its name needed to be changed in its Odoo modules.
Moreover, updated Turkish modules descriptions according to this excalidraw:
https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true

task-4182931





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

Forward-Port-Of: odoo/odoo#182743
Forward-Port-Of: odoo/odoo#180758

odoo/enterprise#69056 Forward-Port-Of: odoo/odoo#178173

odoo/enterprise#69056

Forward-Port-Of: odoo/odoo#178173

### Steps to reproduce: - Install **pos_loyalty** module - Go to **Point of Sale** app > **Products** > **Discount & Loyalty** - Create a **New** program with: - **Program Type**: Next Order Coupons - **Validity**: Today's date for example - Conditional rule with a **Minimum Purchase** of 0.00 - Start a new POS session. Add a product and click **Payment**. - **Validate** the order. - In the receipt shown, notice how the text show **_'Valid until: no expiration'_** althoug

### Steps to reproduce:
- Install **pos_loyalty** module
- Go to **Point of Sale** app > **Products** > **Discount & Loyalty**
- Create a **New** program with: 
    - **Program Type**: Next Order Coupons 
    - **Validity**: Today's date for example 
    - Conditional rule with a **Minimum Purchase** of 0.00
- Start a new POS session. Add a product and click **Payment**.
- **Validate** the order.
- In the receipt shown, notice how the text show **_'Valid until: no expiration'_** although a Validity date is defined!

### Investigation:
- In `confirm_coupon_programs`, `coupon_create_vals` lacks `expiration_date` https://github.com/odoo/odoo/blob/03856863a644fbc588edb6e63168a6c4e15d5d92/addons/pos_loyalty/models/pos_order.py#L72-L78
- To add the `expiration_date`, `date_to` has to be in `coupon_data` but it's not included.
- `coupon_data` comes from https://github.com/odoo/odoo/blob/03856863a644fbc588edb6e63168a6c4e15d5d92/addons/pos_loyalty/static/src/js/PaymentScreen.js#L78

opw-3838427

Forward-Port-Of: odoo/odoo#170295
Forward-Port-Of: odoo/odoo#160633