**Problem:**
An SLA policy that excludes some stages should not count the time a ticket spends in those stages towards its deadline. When the excluded stage is the one the ticket is created in, that waiting time is not deducted and the deadline is too early.

**Steps to reproduce:**
1. In a Helpdesk team using SLA policies, create an SLA whose target stage is a later stage and that excludes the first stage.
2. Create a ticket and leave it in the first (excluded) stage a while.
3. Move it to the next stage.
4. Check the SLA deadline.

**Current behavior:**
The deadline is the creation date plus the SLA time only, ignoring the time spent in the excluded starting stage.

**Expected behavior:**
The deadline should be pushed back by the time spent in the excluded stage, as it already is for stages excluded later in the ticket's life.

**Cause of the issue:**
`_get_freezed_hours` rebuilds the stage history from the ticket's `message_ids.tracking_value_ids`. The deadline is recomputed while the stage change is being written, but the tracking value for that change does not exist yet at that point. When the ticket leaves its creation stage there is no earlier tracking value either, so the method returns 0 and no freeze time is added.

**Fix:**
The stage the ticket is leaving is read from the pending tracking values (`cr.precommit.data`), the same source the duration mixin uses to bridge this exact gap. This makes the freeze time available while the stage change is being written, so it is added to the deadline whether or not that stage's entry was already tracked.

opw-6352099

### Problem

The web client refers to a line it has not saved yet by a virtual id, a string such as `"virtual_42"`. It may send that id back to the server in an `UPDATE` or a `SET` command on an x2many field, for instance after saving a record and editing the same form again without reloading it.

`Base.onchange` adds that string to the ids it prefetches for the lines, and PostgreSQL rejects the query:

```
File "/odoo/addons/web/models/models.py", line 936, in onchange
  lines.fetch(sub_fields_spec.keys())
...
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "virtual_42"
LINE 1: ...res_partner" WHERE ("res_partner"."id" IN (64534, 'virtual_4...
```

The record is saved, so no data is lost, but the user gets a server error on the next change and has to reload the page.

**Steps to reproduce**

1. Open a contact, add a new line under *Contacts & Addresses*, and save.
2. Keep editing the same form without reloading the page.
3. The next onchange returns the error above.

### Fix

Only `CREATE` can carry a virtual id, as the `ref` of a new record. `NewId()` reads such a string as an *origin* instead, so filtering the prefetch is not enough: the id reaches the database a few frames later, through the cache.

The commands are normalized before they are used: an `UPDATE` on a line that is not saved yet becomes a `CREATE` with the same ref, and `SET` and `LINK` drop the ids they cannot resolve.

Unchanged in 18.0, saas-18.4, 19.0 and master.

I hereby agree to the terms of the CLA available at: https://www.odoo.com/cla

Commit: https://github.com/odoo/odoo/commit/68343a56ef0e727c8ac0be4875bedd0fb7460d04 added the possibility of having a negative value for taxable amount in zatca xml to fix this warning:

[202] BR-O-08 : [BR-O-08]-In a VAT
breakdown (BG-23) where the VAT category code (BT-118) is ' Not subject
to VAT' the VAT category taxable amount (BT-116) shall equal the sum of
Invoice line net amounts (BT-131) minus the sum of Document level
allowance amounts (BT-92) plus the sum of Document level charge amounts
(BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are 'Not
subject to VAT'.

It was removed by https://github.com/odoo/odoo/commit/46ede829705dd043d60e4928d14a1ccfa71ffe9b but this was not the right approach. This commit reintroduce https://github.com/odoo/odoo/commit/68343a56ef0e727c8ac0be4875bedd0fb7460d04

This commit also fix the error when sending an invoice with a 0% or a sale order with a down payment:
- Create a sale order with a 0%.
- Create a downpayment and process it by zatca
- Process the delivery on the SO and create the final invoice.
- The invoice will be rejected by zata with the error:

BR-KSA-80 If Pre-Paid amount (BT-113) is
provided then the Pre-Paid
amount (BT-113) must equal to
the sum total of the Prepayment
VAT category Taxable Amount
(KSA-31) and Prepayment VAT
Category Tax Amount (KSA-32)

If the line is a downpayment, then we take the absolute value.

opw-5072577


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

Forward-Port-Of: odoo/odoo#283009

Issue:
On the Mexican localization the caption shown next to the wage on the contract form did not match the selected "Schedule Pay": a contract set to be paid monthly could still display the wage as "/ weekly", which is misleading and led users to enter a weekly minded amount for a wage the engine actually treats as a monthly base.

Steps to reproduce:
- Install the l10n_mx localization
- Open a Mexican contract and set Schedule Pay to Monthly
- Check the caption displayed next to the Wage field

Cause:
The wage period caption is driven by the base schedule_pay field, while MX contracts drive their frequency through `l10n_mx_schedule_pay_temp` and keep the base field hidden. When both get out of sync the caption reflects the hidden base value instead of the frequency the user selected. https://github.com/odoo/enterprise/blob/5f9cf56372a7faa1bce55c418454d3aacbff04c4/hr_payroll/views/hr_contract_views.xml#L36-L48

Solution:
Drive the wage caption from `l10n_mx_schedule_pay_temp` for Mexican contracts so it always matches the schedule pay actually selected, and hide the base schedule_pay captions for MX to avoid the mismatch.

opw-6564087

When scanning a barcode with elements in stock the gs1 barcode generated with have a gosh trailing control character \x00 that will create a traceback when scanned.

Steps to reproduce:
-------------------
* Enable GS1
* Create a Product tracked by lot, with barcode 11614141111417
* Create a lot 1111 for this product with units in stock
* Inventory>Products>Lots / Serial Numbers
  - select the lot number and print it
* From barcode > Inventory Count > scan the printed barcode
-> it will trigger a traceback because of a trailling \x00 character

Observation:
-------------
**Create the DataMatrix**
When downloading the barcode it will call report_download from there it will render the template:
https://github.com/odoo/odoo/blob/d4f592a6b81b83543fcbf644564b992adddc8684/addons/web/controllers/report.py#L120
The template is stock.report_lot_label where it will print the barcode as a ECC200DataMatrix:
https://github.com/odoo/odoo/blob/90ee4710064f39086150045ee3f82023eafb224f/addons/stock/report/report_lot_barcode.xml#L34
The final barcode comes from the view directly:
https://github.com/odoo/odoo/blob/90ee4710064f39086150045ee3f82023eafb224f/addons/stock/report/report_lot_barcode.xml#L25-L26
To create the barcode image it will use createBarcodeDrawing from reportlab:
https://github.com/odoo/odoo/blob/d4f592a6b81b83543fcbf644564b992adddc8684/odoo/addons/base/models/ir_actions_report.py#L721

**Scan the barcode**
- Scanning from Inventory Count:
When scanning the barcode it will use detectCode:
https://github.com/odoo/odoo/blob/bbbd7b6581c1c84d655b1ad96fdab3bd9e40e3c5/addons/web/static/src/core/barcode/barcode_video_scanner.js#L152
where in our case the incorrect character is already present is code.rawValue.
Since we scanned from the count inventory, it will directly recognise the nomenclature and decompose it as a gs1 barcode,
during this process there is a small sanitization of the value in cleanBarcode:
https://github.com/odoo/odoo/blob/3c34811649b9454a58015f5521d63bdebb5b857d/addons/barcodes_gs1_nomenclature/static/src/js/barcode_parser.js#L157-L167
But it doesn't clean the final character.
It will try to process the barcode, where it will retrieve the record from cache:
https://github.com/odoo/enterprise/blob/242111580da73aa432ff87b3c14a95441ea643b0/stock_barcode/static/src/models/barcode_model.js#L735-L738
Since the final character is still present, it will send it and this will trigger an error:
https://github.com/odoo/enterprise/blob/068dc8a241150ac2a05791482ab7549596df8816/stock_barcode/controllers/stock_barcode.py#L185

- Scanning from main barcode page dialog:
This process is a little different if we scan directly from the main barcode page,
when clicking on the barcode image on the main page, it will openManualBarcodeDialog:
https://github.com/odoo/enterprise/blob/c98e5b092481d6334f38c1fbbcfb00e453add958/stock_barcode/static/src/main_menu/main_menu.xml#L24-L25
From there when it detectCode it will call _onBarcodeScanned using the Dialog, barcodeDetected>onResult>onResult:
https://github.com/odoo/enterprise/blob/b2e8429065202cd3c788bf4f1da8559ca75dbe93/stock_barcode/static/src/main_menu/main_menu.js#L57-L62
and it will make an rpc call to scan_from_main_menu:
https://github.com/odoo/enterprise/blob/adc40f2ee0cdbcaf5d6a2a26dc5a3a949aaf7559/stock_barcode/static/src/main_menu/main_menu.js#L98-L99
that will trigger a similar error.

**Reportlab**
ReportLab always encodes Data Matrix payloads using C40 encoding, that encoding is documented in ISO/IEC 16022 §7.2.5.3.

the c40 encoding works by:
  1) converting the data values into c40 value or pair of values
  2) grouping c40 value by three
  3) packing each triplet into two codewords.

The ReportLab implementation correctly performs the C40 packing but does not correctly implement the end-of-data rules
   - Rule b: if two C40 values remain, append a Shift 1 value (0) to complete the final triplet.
   - Rules c and d: if only one C40 value remains, the final character must be encoded using ASCII (with or without an explicit unlatch, depending on the remaining symbol capacity).
The current ReportLab implementation applies the behavior from rule b to the use case of rule "c" and "d".
Which mean it add two Shift 1 value (0) to complete the triplet, as a result the final it decode into an incorrect character.

Also an interesting point to notice is that in this implementation the size is harcoded to 144 (cw_data), this means it falls into the "larger symbol size" case
and can ignore several edge cases where the limited size matters (like difference between rule "c" and "d", which it's also not implemented).
Since it add padding, before the padding it unlatch (value 254).

opw-6268062

When scanning a barcode with elements in stock the gs1 barcode generated with have a gosh trailing control character \x00 that will create a traceback when scanned.

Steps to reproduce:
-------------------
* Enable GS1
* Create a Product tracked by lot, with barcode 11614141111417
* Create a lot 1111 for this product with units in stock
* Inventory>Products>Lots / Serial Numbers
  - select the lot number and print it
* From barcode > Inventory Count > scan the printed barcode
-> it will trigger a traceback because of a trailling \x00 character

Observation:
-------------
**Create the DataMatrix**
When downloading the barcode it will call report_download from there it will render the template:
https://github.com/odoo/odoo/blob/d4f592a6b81b83543fcbf644564b992adddc8684/addons/web/controllers/report.py#L120
The template is stock.report_lot_label where it will print the barcode as a ECC200DataMatrix:
https://github.com/odoo/odoo/blob/90ee4710064f39086150045ee3f82023eafb224f/addons/stock/report/report_lot_barcode.xml#L34
The final barcode comes from the view directly:
https://github.com/odoo/odoo/blob/90ee4710064f39086150045ee3f82023eafb224f/addons/stock/report/report_lot_barcode.xml#L25-L26
To create the barcode image it will use createBarcodeDrawing from reportlab:
https://github.com/odoo/odoo/blob/d4f592a6b81b83543fcbf644564b992adddc8684/odoo/addons/base/models/ir_actions_report.py#L721

**Scan the barcode**
- Scanning from Inventory Count:
When scanning the barcode it will use detectCode:
https://github.com/odoo/odoo/blob/bbbd7b6581c1c84d655b1ad96fdab3bd9e40e3c5/addons/web/static/src/core/barcode/barcode_video_scanner.js#L152
where in our case the incorrect character is already present is code.rawValue.
Since we scanned from the count inventory, it will directly recognise the nomenclature and decompose it as a gs1 barcode,
during this process there is a small sanitization of the value in cleanBarcode:
https://github.com/odoo/odoo/blob/3c34811649b9454a58015f5521d63bdebb5b857d/addons/barcodes_gs1_nomenclature/static/src/js/barcode_parser.js#L157-L167
But it doesn't clean the final character.
It will try to process the barcode, where it will retrieve the record from cache:
https://github.com/odoo/enterprise/blob/242111580da73aa432ff87b3c14a95441ea643b0/stock_barcode/static/src/models/barcode_model.js#L735-L738
Since the final character is still present, it will send it and this will trigger an error:
https://github.com/odoo/enterprise/blob/068dc8a241150ac2a05791482ab7549596df8816/stock_barcode/controllers/stock_barcode.py#L185

- Scanning from main barcode page dialog:
This process is a little different if we scan directly from the main barcode page,
when clicking on the barcode image on the main page, it will openManualBarcodeDialog:
https://github.com/odoo/enterprise/blob/c98e5b092481d6334f38c1fbbcfb00e453add958/stock_barcode/static/src/main_menu/main_menu.xml#L24-L25
From there when it detectCode it will call _onBarcodeScanned using the Dialog, barcodeDetected>onResult>onResult:
https://github.com/odoo/enterprise/blob/b2e8429065202cd3c788bf4f1da8559ca75dbe93/stock_barcode/static/src/main_menu/main_menu.js#L57-L62
and it will make an rpc call to scan_from_main_menu:
https://github.com/odoo/enterprise/blob/adc40f2ee0cdbcaf5d6a2a26dc5a3a949aaf7559/stock_barcode/static/src/main_menu/main_menu.js#L98-L99
that will trigger a similar error.

**Reportlab**
ReportLab always encodes Data Matrix payloads using C40 encoding, that encoding is documented in ISO/IEC 16022 §7.2.5.3.

the c40 encoding works by:
  1) converting the data values into c40 value or pair of values
  2) grouping c40 value by three
  3) packing each triplet into two codewords.

The ReportLab implementation correctly performs the C40 packing but does not correctly implement the end-of-data rules
   - Rule b: if two C40 values remain, append a Shift 1 value (0) to complete the final triplet.
   - Rules c and d: if only one C40 value remains, the final character must be encoded using ASCII (with or without an explicit unlatch, depending on the remaining symbol capacity).
The current ReportLab implementation applies the behavior from rule b to the use case of rule "c" and "d".
Which mean it add two Shift 1 value (0) to complete the triplet, as a result the final it decode into an incorrect character.

Also an interesting point to notice is that in this implementation the size is harcoded to 144 (cw_data), this means it falls into the "larger symbol size" case
and can ignore several edge cases where the limited size matters (like difference between rule "c" and "d", which it's also not implemented).
Since it add padding, before the padding it unlatch (value 254).

opw-6268062