Daily updates from Odoo
Thursday, July 16, 2026
52 changes
4 changes
Resolved issues and error corrections
Rental pickup and return receipts now include the selected invoicing and shipping addresses when customer addresses are enabled. This ensures customers and staff see the complete address details on rental documents, reducing confusion during pickup, return, and billing.
Original PR description
**Steps to Reproduce:** 1. Install sale_renting and enable "Customer Addresses" in the settings 2. Confirm a rental order with shipping address and invoice address 3. Print the Pickup and Return Receipt **Issue:** Only the general partner address is printed; the invoicing/shipping `information_block` is missing **Why this happens:** The 19.2 layout rework (abf18ba250bae2f390f93f70abef1d7fb601c524) switched `web.external_layout` calls to accept macro arguments (e.g. `address="address"`). report_rental_order_document was only partially migrated: `address` was set above the t-call and passed as an argument, but `information_block` was left as a t-set inside the call body, which was the old convention. Once external_layout is called with explicit arguments, content t-set nodes in the body no longer populate the callee's scope, so address_layout's `t-if="information_block"` never triggers. opw-6366091 Forward-Port-Of: odoo/enterprise#124077
Fixed an issue in Mexican payroll where adding Daily Salary or Integration Factor fields to payslip forms with Odoo Studio could trigger an error before an employee was selected. Payroll users can now display these fields and create off-cycle payslips without the form crashing.
Original PR description
Users frequently use Odoo Studio to display the Daily Salary (`l10n_mx_daily_salary`) and Integration Factor (`l10n_mx_integration_factor`) fields on the payslip form to verify salary rule…
Users frequently use Odoo Studio to display the Daily Salary (`l10n_mx_daily_salary`) and Integration Factor (`l10n_mx_integration_factor`) fields on the payslip form to verify salary rule computations. However, doing so raises a traceback immediately upon closing the Studio editor, as well as when attempting to create a new Off-Cycle payslip.
### Steps to reproduce:
* Install `l10n_mx_hr_payroll` and `web_studio`.
* Switch to "INNOVACION VALOR Y DESARROLLO SA SA" company.
* Go to Payroll > Payslips > Payslips and create a "New Off-Cycle"
* Use the Studio editor to add `l10n_mx_daily_salary` or `l10n_mx_integration_factor` fields.
* Close the Studio editor.
### Current behavior:
A traceback is raised depending on the field added
#### For the Daily Salary field:
```py
File "/Users/ivgm/odev/worktrees/19.0/enterprise/l10n_mx_hr_payroll/models/hr_payslip.py", line 21, in _compute_daily_salary
payslip.l10n_mx_daily_salary = payslip.version_id.wage / payslip._rule_parameter('l10n_mx_schedule_table')[payslip.version_id.schedule_pay]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: False
```
#### For the Integration Factor field:
```py
File "/Users/ivgm/odev/worktrees/19.0/enterprise/l10n_mx_hr_payroll/models/hr_payslip.py", line 33, in _compute_integration_factor
payslip.employee_id.with_context(before_date=payslip.date_from)._get_first_contract_date()
File "/Users/ivgm/odev/worktrees/19.0/odoo/addons/hr/models/hr_employee.py", line 493, in _get_first_contract_date
versions = self._get_first_versions_filtered(no_gap=no_gap).filtered(lambda x: x.contract_date_start)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/ivgm/odev/worktrees/19.0/odoo/addons/hr/models/hr_employee.py", line 461, in _get_first_versions_filtered
self.ensure_one()
File "/Users/ivgm/odev/worktrees/19.0/odoo/odoo/orm/models.py", line 5942, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.employee()
```
### Expected behavior:
No error is raised, and the fields are correctly displayed on the form view.
### Solution:
* Add Guard Clause: When creating a "New Off-Cycle" payslip, `payslip.version_id` is not initially set because no employee has been selected yet. Added a condition to check if `version_id` exists before computing the values to prevent the traceback.
* View Update: Since displaying these fields is a highly requested feature for traceability, they have now been added to the form view.
target: 19.0
task-6267003
Forward-Port-Of: odoo/enterprise#121718Belgian payroll now updates an employee's work location details when payroll location settings are added or changed. This ensures the correct regional tax and reduction options, such as the Impulsion Plan, appear without needing to manually change the employee address.
Original PR description
[FIX] l10n_be_hr_payroll: fix stale location unit
Bug reproduction:
1 - L10n_be -> belgium company
2 - create employee and assign work address My Belgium Company
3 - Payroll settings -> Work address DMFA codes -> add My Belgium Company to there -> Competence: Wallonia
4 - Go back to employee -> payroll tab -> In taxes & reduction section you need to see Impulsion Plan field.
Bug cause:
1 - Right now, version's location_unit changes only address_id is changed
2 - When new location_unit is added or when location_unit is edited, it does not reflect to version's location.
Bug solution:
1 - In L10n_BeDmfaLocationUnit model, in create and write functions I'm adjusting the location_units of the affected versions.
2 - Since location_unit is fixed, l10n_be_working_region is fixed as well.
task - 6355995The Belgian payroll app could fail to install on databases that already contained employee departure data because part of the setup ran before all required payroll records existed. This fix lets the installation continue safely instead of stopping with an error.
Original PR description
Currently during the installation process the compute is called before the data of the module is loaded. The compute uses a env.ref that searches for an external id that will only exist later on. this creates a traceback in populated databases, since the compute will be processed, and the app won't be installed. Here we cannot overwrite the auto_init since the field is not stored The only option left was to adapt the comupte to not throw a traceback in case the fields are not found, and instead proceed with the compute/installation opw-6340800 Forward-Port-Of: odoo/enterprise#123744
8 changes
Resolved issues and error corrections
Indian GST reports now better match legal reporting requirements for imports. Import of services is no longer shown in GSTR-2B, and GSTR-3B import reporting has been aligned with the latest section changes for goods and services.
Original PR description
As per the law, import of services is not required to be shown in GSTR-2B. Therefore, the related report lines are removed in this commit. Additionally, GSTR-3B reporting is now handled according to the updated section changes for import of goods and services. task-6330737 Forward-Port-Of: odoo/enterprise#124316 Forward-Port-Of: odoo/enterprise#121925
This fixes an issue where attendee emails could show an outdated event start date after a multi-day event was rescheduled. Event registrations now refresh their stored date information when the event dates change, helping prevent incorrect details from being sent to attendees.
Original PR description
Steps to reproduce: ------------------------------------------------ 1. Install Event module 2. Create a multi day event 3. Create one attendee for the event 4. Change the event dates 5. Go to…
Steps to reproduce: ------------------------------------------------ 1. Install Event module 2. Create a multi day event 3. Create one attendee for the event 4. Change the event dates 5. Go to attendee and Click on Send by Email Observation: ------------------------------------------------ The event start date displayed in the email body is not updated after the event dates are modified. Issue: ------------------------------------------------ In `saas-18.2`, `event_begin_date` and `event_end_date` were simple related fields that automatically updated when their source fields changed. https://github.com/odoo/odoo/blob/saas-18.2/addons/event/models/event_registration.py#L57-L58 However, in `saas-18.3`, slots were introduced and these fields were converted to computed fields https://github.com/odoo/odoo/pull/205945/changes/e2bf8a89d6a50bd40f4673bef38176465f83ba0f * `event_begin_date` is made stored for cohort view grouping * However, the base compute method only depends on `event_id` and `event_slot_id` https://github.com/odoo/odoo/blob/ac37b479321dbe9dbf864e833900e043b1cc70df/addons/event/models/event_registration.py#L177-L180 * When you change `event.date_begin` or `event.date_end`, the registration records don't recompute because the dependency is on the `event_id`, not on the related date fields (`event_id.date_begin`, `event_id.date_end`) * Non-stored computed fields recalculate on-the-fly when accessed, so `event_end_date` appeared to work * Stored computed fields only recalculate when their explicit dependencies change Solution: ------------------------------------------------ * Corrected the dependencies of `_compute_event_begin_date` to recompute value on changing the date of the event opw-6284576 Forward-Port-Of: odoo/enterprise#120184
This fixes several details in Hong Kong IRD payroll reports so the reported tax year matches the employee's start or leaving date. It also ensures a required explanation is included when an employee leaving reason is marked as 'Other', helping submissions meet IRD certification requirements.
Original PR description
As we now have complete support for IRD reports (in master), we started to try to get our system certified by the IRD.
A first submission highlighted a few issues that we are now fixing.
From 19.0:
- In IR56F, the RTN_ASS_YR should be the tax year in which the employee left the company. E.g. after april, the next year.
- In the same report, if the code for the cessation reason is 5 (other), the reason MUST be provided.
From 19.2:
- Same change has to be done when setting RTN_ASS_YR for IR56G
- A same change has to also be done for IR56E, based on the date the employee joined the company.
task-6332150
Forward-Port-Of: odoo/enterprise#124256
Forward-Port-Of: odoo/enterprise#121877VoIP call recordings made from Apple mobile devices could previously be saved as silent audio. The recording quality setting has been adjusted so these recordings capture sound correctly, helping users reliably review calls.
Original PR description
Before this commit, recording a VoIP phone call from an Apple mobile device generated a silent audio file. This issue happened because the configured 8000 `audioBitsPerSecond` value was too low. Apple mobile browsers strictly respect this value, while other browsers ignore it and default to a higher bitrate to 128000. Increasing `audioBitsPerSecond` to 32000 on WebKit browsers fixes the issue on Apple mobile devices. How to reproduce: - Set up a DIDWW user. - Enable call recording. - Make a call. - Open the call and play the recording. opw-6046534 Forward-Port-Of: odoo/enterprise#117885
Chilean Point of Sale receipts with official SII barcodes now print correctly again. This prevents checkout staff from encountering a crash when validating and printing orders for companies using Chilean electronic invoicing.
Original PR description
Steps to reproduce: - Have a Chilean company with DTE configured (a resolution number/date and a signed boleta/factura, so the order's move has an SII barcode) - Open a PoS session, pay an order and validate it Issue: The receipt fails to render and printing crashes with: `TypeError: ctx.image.l10n_cl_sii_barcode_image.to_base64 is not a function` Cause: Commit 0b50021bdae adapted this template as part of the BinaryValue migration (odoo/odoo#244421), calling `to_base64()` on the barcode image. However `l10n_cl_sii_barcode_image` is a computed `fields.Char` that already holds a base64 string (`_pdf417_barcode` returns `b64encode(...).decode()`), not a Binary, so it is never wrapped in a `BinaryValue`. Moreover, this template is also rendered client-side by the PoS QWeb engine, where the value loaded from the server is a plain string with no `to_base64` method either. opw-6389718
Belgian blackbox POS devices are now locked only after the first signed order, instead of when the POS is merely opened. This prevents businesses from accidentally tying a device to a POS before any sale is made, while also improving cost center handling and clearer blackbox error messages.
Original PR description
- `log_device` registered the device as soon as a blackbox POS was opened, so a device was locked before making any sale. Register it only once the config has at least one signed order, and add unit tests covering both branches. - correctly `trim()` cost center - display details inside syntax error & invalid input blackbox error popups
This fix prevents the Belgian payroll app from failing during installation when some setup data is not loaded yet. Businesses can now install or update the app on populated databases without encountering this blocking error.
Original PR description
Currently during the installation process the compute is called before the data of the module is loaded. The compute uses a env.ref that searches for an external id that will only exist later on. this creates a traceback in populated databases, since the compute will be processed, and the app won't be installed. Here we cannot overwrite the auto_init since the field is not stored The only option left was to adapt the comupte to not throw a traceback in case the fields are not found, and instead proceed with the compute/installation opw-6340800 Forward-Port-Of: odoo/enterprise#123744
Fixes an issue where German point-of-sale receipts could fail to download or print when Fiskaly certification data was present. This helps shops using German fiscal certification reliably access receipts from the backend.
Original PR description
With fiskaly in production, when printing the pos receipt, it crashes because the tss values dictionnary is not correctly interacted with. To reproduce: install l10n_de_pos_cert create a DE shop activate fiskaly and the tss in the settings of the POS create an order in the POS and pay it go to the backend, open the pos order and download the receipt it will crash To reproduce without production credentials, you can not activate fiskaly and the tss but still create and pay the pos order. Then, you can change the pos.config to add the l10n_de_fiskaly_tss_id and change the pos.order to add the l10n_de_fiskaly_time_start. Then download the receipt. opw-6356628 Fixes https://github.com/odoo/enterprise/pull/115676 Forward-Port-Of: odoo/enterprise#123473
5 changes
Resolved issues and error corrections
Fixed an issue where product variants using cost-based pricelists showed an outdated on sale price after the product cost was changed. Prices now refresh immediately, helping sales teams and cashiers see accurate promotional pricing without needing another update.
Original PR description
When we create a product variant and have a pricelist which is based on the cost price, and change the cost price, the on_sale_price doesn't update correctly. It gets delayed by one update because the product._origin isn't getting updated with the new onchanged value. Steps to Reproduce: 1.Create a pricelist and add a line with "formula" price type, and based on "cost", 2.Create a product variant, and add the pricelist just created. 3.Change the "Cost". The "On Sale Price" updates based on the value before. To fix the issue, we need to update the product._origin for standard_price just like the lst_price before computing the on_sale_price opw-5947995 Forward-Port-Of: odoo/enterprise#120420 Forward-Port-Of: odoo/enterprise#119470
The Indian GST reports now exclude imported services from GSTR-2B, matching current legal requirements. GSTR-3B reporting for imported goods and services has also been updated to use the latest required sections, helping businesses file more accurate tax reports.
Original PR description
As per the law, import of services is not required to be shown in GSTR-2B. Therefore, the related report lines are removed in this commit. Additionally, GSTR-3B reporting is now handled according to the updated section changes for import of goods and services. task-6330737 Forward-Port-Of: odoo/enterprise#124316 Forward-Port-Of: odoo/enterprise#121925
Preparation tickets now load the required styling again after a recent receipt printing change, so kitchen and order tickets display as expected. The update also restores missing receipt details, including customer notes, and improves related point-of-sale receipt screens.
Original PR description
..., pos_restaurant, pos_self_order, pos_urban_piper --- During the refactor of the receipt printing system, some CSS classes were no longer loaded with preparation tickets. As a result, preparation tickets lost part of their original styling. To restore the expected rendering, ensure all required classes are properly loaded while keeping the loading minimal. Additionally, some receipt data were missing after the refactor and some UI elements could be improved. This commit restores the missing data and improves the overall UI. It also fixes an issue where customer notes were not printed on the receipt. Templates checked: * point_of_sale.pos_order_change_receipt * point_of_sale.pos_order_change_receipt_line --- Task: https://www.odoo.com/odoo/project/1737/tasks/6133403 Refacto: https://github.com/odoo/odoo/pull/244395
Fixed an issue that could prevent German point-of-sale receipts from being downloaded or printed when Fiskaly certification data was present. This helps stores using German fiscal certification reliably access receipts from completed POS orders.
Original PR description
With fiskaly in production, when printing the pos receipt, it crashes because the tss values dictionnary is not correctly interacted with. To reproduce: install l10n_de_pos_cert create a DE shop activate fiskaly and the tss in the settings of the POS create an order in the POS and pay it go to the backend, open the pos order and download the receipt it will crash To reproduce without production credentials, you can not activate fiskaly and the tss but still create and pay the pos order. Then, you can change the pos.config to add the l10n_de_fiskaly_tss_id and change the pos.order to add the l10n_de_fiskaly_time_start. Then download the receipt. opw-6356628 Fixes https://github.com/odoo/enterprise/pull/115676
Call recordings made from Apple mobile devices will no longer result in silent audio files. The VoIP recording settings were adjusted for Apple mobile browsers so recorded calls can be played back correctly.
Original PR description
Before this commit, recording a VoIP phone call from an Apple mobile device generated a silent audio file. This issue happened because the configured 8000 `audioBitsPerSecond` value was too low. Apple mobile browsers strictly respect this value, while other browsers ignore it and default to a higher bitrate to 128000. Increasing `audioBitsPerSecond` to 32000 on WebKit browsers fixes the issue on Apple mobile devices. How to reproduce: - Set up a DIDWW user. - Enable call recording. - Make a call. - Open the call and play the recording. opw-6046534 Forward-Port-Of: odoo/enterprise#117885
8 changes
Resolved issues and error corrections
VoIP call recordings made from Apple mobile devices no longer produce silent audio files. The recording quality setting was adjusted for Apple mobile browsers so businesses can reliably review recorded calls when call recording is enabled.
Original PR description
Before this commit, recording a VoIP phone call from an Apple mobile device generated a silent audio file. This issue happened because the configured 8000 `audioBitsPerSecond` value was too low. Apple mobile browsers strictly respect this value, while other browsers ignore it and default to a higher bitrate to 128000. Increasing `audioBitsPerSecond` to 32000 on WebKit browsers fixes the issue on Apple mobile devices. How to reproduce: - Set up a DIDWW user. - Enable call recording. - Make a call. - Open the call and play the recording. opw-6046534 Forward-Port-Of: odoo/enterprise#117885
This fix restores the display of exchange rate adjustment entries in the bank reconciliation widget. It helps accounting users correctly review and reconcile bank transactions involving currency differences.
Original PR description
Fix a bug where the exchange moves are no more displayed in the bank reco widget. Bug introduced here: https://github.com/odoo/enterprise/pull/119557 no-task Forward-Port-Of: odoo/enterprise#124495
This fixes an issue where Mexican payroll CFDI documents could fail for companies registered as individuals under fiscal regime 621. The system now uses the Mexican tax ID length to detect individual issuers and include the required CURP, allowing payroll documents to be generated successfully.
Original PR description
Issue: ---------------------------------------- There is a fiscal regime where the company is actually an individual but is authorized to generate documents. Steps to reproduce:…
Issue: ---------------------------------------- There is a fiscal regime where the company is actually an individual but is authorized to generate documents. Steps to reproduce: ---------------------------------------- - Install "l10n_mx_hr_payroll_account_edi" - Change the current company fiscal regime to '621' - Add an VAT of length 13 to the current company - Add a CURP number on the current company - In Payroll generate a payslip, validate it - Post the Journal entry - On the payslip, click "Generate CFDI" - An error is returned, saying the Emisor:Curp applies to individuals Cause: ---------------------------------------- An RFC of length 13 means that the sender is an individual. It's intended with the fiscal regime '621'. We add the curp number in the CFDI XML only when `self.company_id.partner_id.is_company` is `False`. Since saas-19.1, `is_company` is computed to be truely if a VAT is present. So as soon as the VAT is entered, the CURP number is absent from the XML. Solution: ---------------------------------------- We change the condition to add the CURP number in the XML: A VAT number of length 13 means the contact is an individual (12 for companies). This is what is used to validate the XML: if the vat is of length 13, then the curp number should be present. opw-6351558
This fixes an issue where some Brazilian customer tax settings were left out when sending invoice data to Avalara. Keeping those settings ensures Avalara applies the correct fiscal operation code, reducing the risk of incorrect tax handling on Brazilian invoices.
Original PR description
## Steps to reproduce: 1. Install `l10n_br`, `l10n_br_avatax`, and `l10n_br_edi_fiscal_reform`. 2. Ensure that Demo mode is activated if not on Runbot. 3. Navigate to Contacts, then click into "BR…
## Steps to reproduce:
1. Install `l10n_br`, `l10n_br_avatax`, and `l10n_br_edi_fiscal_reform`.
2. Ensure that Demo mode is activated if not on Runbot.
3. Navigate to Contacts, then click into "BR Company Customer Estimated Profit".
4. Duplicate this contact, then set the following fields:
1. Tax Regime set to individual
2. ICMS Taxpayer Type set to Non-Taxpayer
5. Swtich to the BR Company and go to Accounting / Configuration / Settings.
6. Set up a Sandbox Avalara account and enable logging payload responses.
7. Navigate to Accounting > Customers > Invoices.
8. Create an invoice with:
1. Customer set to the copy created earlier.
2. Operation Type set to Sale of Goods
3. Document Type set to 55
4. Payment Method Brazil set to Money
5. Presence set to Present
6. One sales order line with:
1. Regular Consumable Product
2. quantity set to 1
3. price set to 100.0
9. Confirm the invoice.
10. Navigate back to Accounting > Configuration > Settings to view the response from Avalara. The customer will have the CFOP 6102 instead of CFOP 6108.
Explanation:
PR #97845 introduced `_l10n_br_deep_clean_dict()` to remove falsy values and empty dictionaries from the payload we send to Avalara. This fix was applied as broadly as possible to prevent excessive if statements.
However, if the falsy values in taxSettings of the customer are not communicated, Avalara will assign the customer to an incorrect CFOP.
opw-6085964This fix prevents an accounting dashboard filter from accidentally affecting payment document creation for Mexican electronic invoices. Users can now update payments without encountering an error caused by invalid document type data being carried over from the dashboard context.
Original PR description
Issue: The `default_type` context can leak into documents creation with invalid values (e.g., 'sale' for documents.document.type), causing a ValueError. Steps to reproduce: - Use a Mexican company with CFDI credentials configured. - Install the documents_account module and create a folder for journals where you will place customer payments. - Create an invoice with "payment policy = PPD", and send it to CFDI. - Create a bank transaction and reconcile it with the invoice. - Go to the Accounting Dashboard, remove current filters, and group by "Type" (this injects default_type into the context). - From there, enter the "Sales" journal and open the invoice. - Click on the "Update Payments" button. - Result: `ValueError: Wrong value for documents.document.type: 'sale'` Fix: Clean context from the `default_*` keys when creating the attachment of the document. opw-6141172 Forward-Port-Of: odoo/enterprise#124399 Forward-Port-Of: odoo/enterprise#124074
Point-of-sale sales in Colombia that include combo products can now be accepted by DIAN. The update prevents zero-priced combo parent lines from being sent in the electronic document, avoiding payment validation errors for affected transactions.
Original PR description
Issue: When ordering through POS combo items won't be accepted by DIAN. Steps to reproduce: Set company to Colombia and activate the DIAN module. Simulate a sell of an combo item with POS. Pay with card. Error will ensue. Cause: The XML sent to DIAN is not accepted because one of the items has 0 price (the combo item). Solution: Not sending lines that are combo items. opw-6232599 Forward-Port-Of: odoo/enterprise#119652
Colombian electronic invoice imports now keep the unit price from the XML as intended by DIAN rules. This prevents incorrect negative discounts from appearing on vendor bills when imported invoice lines use quantities greater than one.
Original PR description
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price…
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal. Solution: Extract the basis_qty logic into a helper method so other localizations can override when needed. Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill. Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied. task-6215466 Forward-Port-Of: odoo/enterprise#124400 Forward-Port-Of: odoo/enterprise#122313
Uruguay electronic credit notes for original e-Tickets with a total of 0.00 now keep the required reference amount in the XML. This prevents DGI rejections for these zero-value credit notes and avoids related processing errors for document types that do not use the field.
Original PR description
Problem: When generating an e-Ticket Credit Note for an original e-Ticket with a total amount of 0.00, the XML cleanup mechanism removes reference fields whose value is 0.00. As a result, the credit note is rejected by DGI with: "CODE 31: En línea de Referencia 1 si NO IndGlobal = 1 deben existir TpoDocRef, Serie, NroCFERef, MntCFERef, TpoMonedaRef." Solution: Ensure that MntCFERef is sent even if the value is 0.00. opw-6378783 Forward-Port-Of: odoo/enterprise#124377 Forward-Port-Of: odoo/enterprise#124354
2 changes
Resolved issues and error corrections
Email links for appointments and related event flows now use the website tied to the appointment or event instead of a generic or recently visited website. This prevents customers in multi-website setups from being sent to the wrong site when managing bookings or registrations.
Original PR description
In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from…
In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from which the request started. Case 1: - Have website A and website B - Create an appointment page website A - Log in via website B - As public user, make an appointment in Website A - Check the generated email Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the appointment. This occurs because when an user log in, the system parameter 'web.base_url' is updated with the current url. This parameter is then used as fallback when we need to retrieve the base url without an active record Case 2: - Have website A and website B - Create an event and assign it to website B - As public user, access the event and register to it - Check the generated email Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the event. This occurs because the record `event.registration` has no website_id field and the base url is taken from the company default website (website A) Backport with improvements of 15bae202d8f1b5bf70bbc63b2d89025e9237e6cf opw-4146760 opw-4336369 Forward-Port-Of: odoo/enterprise#124173 Forward-Port-Of: odoo/enterprise#122669
Uruguayan electronic credit notes for original e-Tickets totaling 0.00 now include the required reference amount field instead of having it removed. This prevents DGI rejections for valid zero-amount credit notes and keeps related document submissions compliant.
Original PR description
Problem: When generating an e-Ticket Credit Note for an original e-Ticket with a total amount of 0.00, the XML cleanup mechanism removes reference fields whose value is 0.00. As a result, the credit note is rejected by DGI with: "CODE 31: En línea de Referencia 1 si NO IndGlobal = 1 deben existir TpoDocRef, Serie, NroCFERef, MntCFERef, TpoMonedaRef." Solution: Ensure that MntCFERef is sent even if the value is 0.00. opw-6378783 Forward-Port-Of: odoo/enterprise#124377 Forward-Port-Of: odoo/enterprise#124354
3 changes
Resolved issues and error corrections
Bank transaction matching now ignores archived bank accounts when automatically selecting a partner. This prevents transactions from being assigned to the wrong partner and keeps automated reconciliation aligned with expected manual matching behavior.
Original PR description
Steps to reproduce: - Have a partner with a bank account, then archive the res.partner.bank record (keep the partner active). - Import or create a bank transaction (e.g. via bank sync) whose account number matches that archived bank account, and whose label/payment_ref would otherwise match a reconciliation model for a different partner. - Let the transaction go through automatic partner retrieval. => The archived bank account's partner is assigned, even though a normal manual entry (which skips the account-number match) would have used the label instead. Cause of the issue: `AccountBankStatementLine._retrieve_partner()` matches statement lines to partners in batch using raw SQL joining `res_partner_bank`. The query's WHERE clause filters out archived partners (`AND partner.active`) but never filters `res_partner_bank.active`. opw-6340479
Invoices marked as excluded from follow-up are now also left out of follow-up email attachments and printed follow-up letters. This prevents customers from receiving documents for invoices that staff intentionally removed from the follow-up process.
Original PR description
Steps to reproduce: 1. Install Accounting and create an invoice for a customer which has a due date in the past 2. Make sure the payment term for the invoice is "Immediate Payment" and Send the…
Steps to reproduce: 1. Install Accounting and create an invoice for a customer which has a due date in the past 2. Make sure the payment term for the invoice is "Immediate Payment" and Send the invoice. 3. Open the contact form and click on the Customer Statement smart button 4. Exclude the invoice using the 'No Follow-Up' toggle 5. In the Accounting tab in the contact form, click on send 6. Open the internal link of the Content Template, go to the options tab and select 'Print Follow-up Letter' in Dynamic Reports 7. Save the configuration and send the email Issue: Excluded invoices still appeared as PDF attachments in the follow-up email and were merged into the printed follow-up letter PDF. Why this happens: Both `default_get` in `account_followup.manual_reminder` and `_get_invoices_to_print` in `res.partner` traversed `unreconciled_aml_ids` without filtering out lines where `no_followup = True`, so excluded invoices were included regardless. opw-6310602 Forward-Port-Of: odoo/enterprise#122249
Fixes Uruguay electronic credit notes so required reference amount information is still sent when the original e-Ticket total is 0.00. This prevents DGI rejections for valid zero-value credit notes and avoids related errors for document types that do not use the same field.
Original PR description
Problem: When generating an e-Ticket Credit Note for an original e-Ticket with a total amount of 0.00, the XML cleanup mechanism removes reference fields whose value is 0.00. As a result, the credit note is rejected by DGI with: "CODE 31: En línea de Referencia 1 si NO IndGlobal = 1 deben existir TpoDocRef, Serie, NroCFERef, MntCFERef, TpoMonedaRef." Solution: Ensure that MntCFERef is sent even if the value is 0.00. opw-6378783 Forward-Port-Of: odoo/enterprise#124377 Forward-Port-Of: odoo/enterprise#124354
9 changes
Resolved issues and error corrections
This fix restores supported flows where portal users need to archive or unarchive documents when the system explicitly grants elevated permission. It also prevents errors in cases where no documents are present, making document handling more reliable.
Original PR description
In #116886, we fixed the blocking of portal users to (un)archive documents, but it appears that some flows did rely on it and we were lacking a way of supporting it. Task-6205627 Forward-Port-Of: odoo/enterprise#123171 Forward-Port-Of: odoo/enterprise#123015
Luxembourg payroll now uses the correct official salary index values for contracts starting from May 2025 and June 2026. This prevents incorrect contract signature index values and helps ensure related payroll calculations reflect current legal parameters.
Original PR description
## Issue When creating or browsing an existing contract in a Luxembourgish company, the current index shown is the one from September 2023 (which was up-to-date until Mai 2025). If the contract is…
## Issue
When creating or browsing an existing contract in a Luxembourgish company, the current index shown is the one from September 2023 (which was up-to-date until Mai 2025). If the contract is created after Mai 2025, the "Index on Contract Signature" field is also wrong.
## Steps to reproduce
1. Install *Luxembourg - Payroll* (`l10n_lu_hr_payroll`)
2. Using a Luxembourgish company, create a new contract for an employee
- *Contract Start Date*: Any date after 05/01/2025 (Mai 1st 2025)
3. __The *Index on Contract Signature* shows `944.43`, which is the index from September 2023. It does not match with the most recent indices.__
## Cause
The two most recent indices are missing from the [`rule_parameter_lu_index`](https://github.com/odoo/enterprise/blob/885edbc270a86ab76e0a6eff4acb5767c0fe29d1/l10n_lu_hr_payroll/data/rule_parameters/general_rules_data.xml#L4-L58). These indices are:
- `968.04` from 2025-05-01 (Mai 1st 2025)
- `992.24` from 2026-06-01 (June 1st 2026)
These values were taken from [here](https://salary.lu/en/tools/social-parameters/indexation-of-salaries) and double-checked [here](https://lustat.statec.lu/?lc=en&tm=DF_C1201&pg=0&snb=1).
## Tests modification
Updating the latest index had an impact on the tests from the `l10n_lu_hr_payroll_account` (testing the salary rules). In fact, the current index (`l10n_lu_current_index`) is [used to compute the indexed wage](https://github.com/odoo/enterprise/blob/7892d035ddb968d67a3e8da0daf91292bd8fb499/l10n_lu_hr_payroll/models/hr_contract.py#L24-L33) (`l10n_lu_indexed_wage`), which is then used to compute most lines in the payslip (e.g., the `WAGE_SUPPLEMENT_70`).
https://github.com/odoo/enterprise/blob/7892d035ddb968d67a3e8da0daf91292bd8fb499/l10n_lu_hr_payroll/data/salary_rules/hr_salary_rule_data.xml#L70-L74
Since the latest index is not the same as when those tests were written, the values are not correct anymore. To prevent this, time was frozen to 01/01/2024 to use the expected index (944.43, from September 2023).
opw-6330790
Forward-Port-Of: odoo/enterprise#122147This fixes incorrect invoice statuses for field service sales orders that include zero-price lines. Existing zero-price quotation lines can now remain invoiceable, while zero-price materials added during field service work are correctly treated as included, preventing orders from staying incorrectly marked as still to invoice.
Original PR description
## [FIX] industry_fsm_sale: fix invoice status for zero price lines ### Issue: Without Anglo-Saxon accounting, the system incorrectly sets the invoice status of all zero price sales order lines…
## [FIX] industry_fsm_sale: fix invoice status for zero price lines
### Issue:
Without Anglo-Saxon accounting, the system incorrectly sets the invoice status of all zero price sales order lines linked to an FSM task to 'no'
This includes pre-existing lines that were already present on the quotation before confirmation. If a zero price line is pre-existing, it should follow the standard flow and be marked as 'to invoice'
Only lines added as materials from the field service task at a zero price should be considered included in the price and marked as 'no'
### Cause:
In `SaleOrderLine._compute_invoice_status`, the system forced `invoice_status = 'no'` for all zero price lines when Anglo-Saxon accounting was disabled
It failed to check if the lines were actually materials added via the FSM task or original quotation lines
### Fix:
A new `material_sale_lines` compute field is added to `project.task` to distinctly isolate and track lines added specifically as materials during the task execution
In `SaleOrderLine._compute_invoice_status`, the logic is updated to ensure that only zero price lines identified as FSM materials are set to 'no' when Anglo-Saxon accounting is disabled
Other pre-existing zero price lines properly remain as 'to invoice'
### Steps to reproduce:
- Install `industry_fsm_sale`
- In Settings > Users & Companies > Companies > Any company, add the field Anglo-Saxon using Studio (In 19.0+)
- Disable Anglo-Saxon on the current company
- Create a product Service (Fixed Price, that create a task in a Field Service Project)
- Create and confirm a Sale Order with the Service and one product with unit price 0
Before the fix, the pre-existing SO line with price 0 is
incorrectly considered as not to invoice ('no')
opw-6169802
------------------------------
## [FIX] industry_fsm_sale: sync sale order invoice status
### Issue:
When a sale order contains FSM material lines with a price of zero and Anglo-Saxon accounting is disabled, the overall sale order invoice status remains stuck on 'to invoice' even after all other invoiceable lines are fully invoiced
### Cause:
The standard `SaleOrder._compute_invoice_status` does not handle FSM business rules regarding zero price material lines that are marked as `invoice_status = 'no'`
Because these lines are never technically invoiced, the global order status fails to transition to 'invoiced'
### Fix:
Override `SaleOrder._compute_invoice_status` to recompute the status of confirmed orders linked to FSM tasks
We use the task's `material_sale_lines` to filter out material components
If all lines on the order are either 'invoiced' or are zero price FSM material lines with Anglo-Saxon disabled, the global sale order status is forced to 'invoiced'
### Steps to reproduce:
- Install `industry_fsm_sale`
- In Settings > Users & Companies > Companies > Any company, add the field Anglo-Saxon using Studio (In 19.0+)
- Disable Anglo-Saxon on the current company
- Create a product Service (Fixed Price, that create a task in a Field Service Project)
- Create and confirm a Sale Order with the Service and one product with unit price 0
- Add a Product from the Task (Use a price 0 product, or set the unit price to 0 on the SO)
- Create the invoice for the Sale Order
Before the fix, the Service and Pre-existing product are invoiced, but in the Other Info Tab of the SO, the status stays on 'To Invoice' instead of 'Fully Invoiced'
opw-6169802
Forward-Port-Of: odoo/enterprise#124190
Forward-Port-Of: odoo/enterprise#119238Payslip creation now correctly includes employees assigned to branch companies when working from a parent company. This helps Belgian payroll teams select the right employees without manual workarounds or missing staff from payroll processing.
Original PR description
Bug: employees registered on branch companies don't appear in the
employee_id field when creating a payslip from the parent company.
Reason: the domain used ('company_id', '=', company_id) which only
matches the exact company, not its children.
Solution: replaced '=' with 'child_of' to include all descendant
companies in the hierarchy.
task - 6299634
Forward-Port-Of: odoo/enterprise#122381
Forward-Port-Of: odoo/enterprise#120974This fixes several Hong Kong IRD payroll report details found during certification testing. Reports now better match IRD requirements for amendment grouping, assessment year calculation, income totals, and required departure information.
Original PR description
As we now have complete support for IRD reports (in master), we started to try to get our system certified by the IRD. A first submission highlighted a few issues that we are now fixing. - There is only two types of XML. Original and 'adjustment'. The adjustment XML mix all three adjustment type in one file, which isn't what we did until now. - In 56E, RTN_ASS_YR must be based on the contract start date and the tax year - In 56F, RTN_ASS_YR must be based on the contract end date and the tax year. Also, the reason of departure MUST be set if departure type is 'other' - In 56G, RTN_ASS_YR must be based on the contract end date and the tax year. task-6309992
Invoice tax recalculations through Avatax now refresh the pre-tax base amount each time, instead of keeping an older cached value. This helps ensure invoice line totals stay consistent with the latest tax calculation returned by Avatax.
Original PR description
Previously, when recomputing taxes via Avatax, `manual_tax_amounts` was cleared and repopulated from the fresh API response, but `manual_total_excluded_currency` was only set if it was None. This meant that after the first Avatax call, the pre-tax base amount was never refreshed from subsequent API responses, even though the tax amounts were. This inconsistency could cause stale pre-tax base amounts to persist on invoice lines across recomputations, even when Avatax returned a different base amount. By resetting `manual_total_excluded_currency` to `None` at the start of each recomputation, mirroring what is already done for `manual_tax_amounts`, we ensure that the pre-tax base is always taken from the current Avatax response rather than a previously cached value. opw-6235597 Forward-Port-Of: odoo/enterprise#124152 Forward-Port-Of: odoo/enterprise#123802
Users with the Invoicing & Banks accounting role can now open the Accounting app without encountering an access error. The change restores a missing read permission needed to load accounting screens, bringing behavior back in line with previous versions.
Original PR description
**Description of the issue/feature this PR addresses:** Users in the 'Accounting / Invoicing & Banks' group were encountering an access error when attempting to open the Accounting app. This was…
**Description of the issue/feature this PR addresses:** Users in the 'Accounting / Invoicing & Banks' group were encountering an access error when attempting to open the Accounting app. This was caused by a missing read access right for the `account.return.type` model that is present in previous versions (e.g. saas-19.3). Without this permission, the basic accounting group (`account.group_account_basic`) is blocked from loading the necessary accounting views. This commit restores the `access_account_return_type_basic` rule, granting read access to the basic accounting group so they can access the app without errors. opw-6377912 **Steps to reproduce:** - Sign in as Mitchell Admin - Settings > Users & Companies > Users > Mitchell Admin > Access Rights > Accounting > Accounting > change to ‘Invoicing & Banks’ - Attempt to access the Accounting app > observe Access Error **Current behavior before PR:** - Users in the 'Accounting / Invoicing & Banks' group are unable to access the Accounting app due to Access Error **Desired behavior after PR is merged:** - Users in the 'Accounting / Invoicing & Banks' are able to access the Accounting app Forward-Port-Of: odoo/enterprise#124174
A payroll correction action now applies to all relevant payslips when used from the popup, regardless of which option is selected. This helps payroll teams avoid missed payslips and reduces the need for manual follow-up when processing corrections in batches.
Original PR description
**What:** - Corrected the method logic 'action_keep_wrong_version' to make sure that it works for both option in the view popup. task-6356957 Forward-Port-Of: odoo/enterprise#124089 Forward-Port-Of: odoo/enterprise#122625
This update fixes an issue that could prevent users from confirming all signatures in the Sign app. It keeps the signature dialog aligned with a related platform change so the signing flow continues to work reliably.
Original PR description
Companion PR to odoo/odoo#274208. That PR converts `NameAndSignature.signatureRef` from an OWL2 compat `useRef` (`.el` accessor) to a `signal.ref` (callable). The `SignNameAndSignature` subclass here still read `this.signatureRef.el` inside `updateFrame`, which became `undefined` and threw "Cannot read properties of undefined (reading 'width')" on the "Sign all" confirm. Read the canvas element via `this.signatureRef()` instead. Companion PR: odoo/odoo#274208
9 changes
Resolved issues and error corrections
Creating an Australian payroll super account could fail because the system used inconsistent internal references when checking employee super contribution proportions. This fix makes that check consistent, preventing the error and allowing payroll configuration to proceed normally.
Original PR description
Version - 19.0 Steps to reproduce(runbot): - Install `l10n_au_hr_payroll` - Go to Payroll -> Configuration -> Super Accounts - Create a Super Account by filling all the required fields - You will…
Version - 19.0
Steps to reproduce(runbot):
- Install `l10n_au_hr_payroll`
- Go to Payroll -> Configuration -> Super Accounts
- Create a Super Account by filling all the required fields
- You will encounter the issue
**TraceBack:**
```
('hr.menu_hr_employee_payroll', 485, 'Employees > Employees', 756):
Traceback (most recent call last):
File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 346, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 377, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 537, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 570, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3490, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3747, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 6688, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1744, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1915, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 484, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4954, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/enterprise/19.0/l10n_au_hr_payroll/models/hr_employee.py", line 118, in _compute_proportion_warnings
proportions[emp.id] * 100,
KeyError: 4
```
Issue:
During the refactoring from `read_group()` to `_read_group()`, the `proportions` dictionary became keyed by `hr.employee` records instead of employee IDs. While the condition was updated to use `proportions.get(emp)`, the warning message still accessed the dictionary using `proportions[emp.id]`, resulting in a `KeyError`.
Fix:
Use the employee record consistently when accessing the `proportions` dictionary after switching to `_read_group()`.
Task ID - 6390373
Refrence:
https://github.com/odoo/enterprise/pull/72217/changes#diff-8ae3564d54e47eec919ef273d44f6276d8c6df60e21c5c8c8f7292b1c38cf541R460This fixes an error that could occur when updating payments on Mexican CFDI invoices after navigating from a grouped accounting dashboard view. The change prevents unrelated screen filters from interfering with document attachment creation, making the payment update process more reliable.
Original PR description
Issue: The `default_type` context can leak into documents creation with invalid values (e.g., 'sale' for documents.document.type), causing a ValueError. Steps to reproduce: - Use a Mexican company with CFDI credentials configured. - Install the documents_account module and create a folder for journals where you will place customer payments. - Create an invoice with "payment policy = PPD", and send it to CFDI. - Create a bank transaction and reconcile it with the invoice. - Go to the Accounting Dashboard, remove current filters, and group by "Type" (this injects default_type into the context). - From there, enter the "Sales" journal and open the invoice. - Click on the "Update Payments" button. - Result: `ValueError: Wrong value for documents.document.type: 'sale'` Fix: Clean context from the `default_*` keys when creating the attachment of the document. opw-6141172 Forward-Port-Of: odoo/enterprise#124074
Belgian blackbox POS devices are now registered only after the POS configuration has a signed order, preventing devices from being locked before any sale occurs. The update also improves handling of cost center names and makes blackbox error messages clearer for users.
Original PR description
- `log_device` registered the device as soon as a blackbox POS was opened, so a device was locked before making any sale. Register it only once the config has at least one signed order, and add unit tests covering both branches. - correctly `trim()` cost center - display details inside syntax error & invalid input blackbox error popups
Studio approval checks now handle rules that reference restricted fields without causing an access error for users who lack those permissions. This prevents valid actions, such as confirming a sales order, from being blocked unexpectedly while keeping approval logic intact.
Original PR description
Issue: A studio.approval.rule.domain includes a related field that calls an access rights group that the user who used the action isn't apart of, Is blocked by the filtered_domain. To Replicate: 1) Install studio, sale, Accounting and make sure "account_followup" is installed 2) create a related field on the sales.order form related to "customer -> follow up status" 3) Save 4) Create a "Studio Approval Rule" (studio.approval.rule) with a domain using the new related studio field -> method : "action_confirm" -> approver:admin 5) create a test user with no accounting access rights 6) in an incognito browser try and create a sales order, and then confirm it. it will throw the access rights error Fix: add a sudo to the filtered_domain opw-6316069
Subscription product tiles in the online shop now show discounts based on the correct recurring price rather than the one-time sale price. This prevents customers from seeing misleading monthly prices before opening the product page.
Original PR description
Steps to reproduce: =================== 1. Create a subscription product, allow one-time sale, sale price 5 2. Add a recurring price 10/month 3. On the pricelist, add an advanced rule: -10% for the…
Steps to reproduce: =================== 1. Create a subscription product, allow one-time sale, sale price 5 2. Add a recurring price 10/month 3. On the pricelist, add an advanced rule: -10% for the monthly plan 4. Open the shop page and look at the product tile Cause: ======= On the /shop page, the subscription price displayed on a product tile is computed by `_get_sales_prices`. The cart has no plan selected yet at that point, so `request.cart.plan_id.id` is empty and was passed as `plan_id` to `_compute_price`. In `product.pricelist.item._compute_base_price`, the recurring base price is only looked up when a `plan_id` is given: if rule_base == 'list_price' and product.recurring_invoice and plan_id: ... # find the recurring rule -> base = recurring price With `plan_id` empty, that branch is skipped and the percentage rule falls back on the product's one-time `list_price` instead of the recurring price. Example: one-time price 5, recurring price 10/month, pricelist rule -10% on the monthly plan. => Tile showed 4.5/month (5 * 0.9) instead of 9/month (10 * 0.9). Solution: ========= The chosen pricing already targets a plan, so pass `pricing.plan_id.id` to `_compute_price`, matching what the product page does in `_get_additionnal_combination_info`. opw-6307398
French VAT reports now only include a direct debit payment order when VAT is actually owed. This prevents refund requests from being rejected by the French tax authority because an invalid payment block was attached.
Original PR description
`_prepare_edi_vals` always called `_get_formatted_payment_values()`, adding an EDI-Paiement (telereglement) block to the T-IDENTIF of the 3310CA3, regardless of whether the company owes VAT or is in…
`_prepare_edi_vals` always called `_get_formatted_payment_values()`, adding an EDI-Paiement (telereglement) block to the T-IDENTIF of the 3310CA3, regardless of whether the company owes VAT or is in a credit position. Steps to reproduce: - French company in a VAT credit position, requesting a refund. - Fill a bank account line, the account to receive the refund and send the VAT report to the DGFiP. Current behaviour: The DGFiP returns a negative acknowledgement on the CA3 interchange: "Telereglement 1 rejete: Montant telereglement absent ou invalide. Code erreur : 018", even though the declaration itself is accepted. The wizard's bank account lines are reused for two opposite purposes: the account to debit when VAT is due, and the account to credit when a refund is asked. `_get_formatted_payment_values()` builds a payment order from them unconditionally, so a telereglement for the credit amount is emitted in the refund case. A telereglement is invalid when no VAT is due, hence error 018. A return nets to either a payment or a credit, never both, so the two cases are mutually exclusive. This commit guards the call with `self.is_vat_due`, so the telereglement is only generated when the company actually owes VAT. The VAT-due flow is unchanged. opw-6275695
Email buttons for public appointment and event interactions now use the website linked to the appointment or event instead of an unrelated site visited during login. This prevents customers on multi-website setups from being sent to the wrong website when managing appointments or registrations.
Original PR description
In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from…
In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from which the request started. Case 1: - Have website A and website B - Create an appointment page website A - Log in via website B - As public user, make an appointment in Website A - Check the generated email Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the appointment. This occurs because when an user log in, the system parameter 'web.base_url' is updated with the current url. This parameter is then used as fallback when we need to retrieve the base url without an active record Case 2: - Have website A and website B - Create an event and assign it to website B - As public user, access the event and register to it - Check the generated email Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the event. This occurs because the record `event.registration` has no website_id field and the base url is taken from the company default website (website A) Backport with improvements of 15bae202d8f1b5bf70bbc63b2d89025e9237e6cf opw-4146760 opw-4336369 Forward-Port-Of: odoo/enterprise#124173 Forward-Port-Of: odoo/enterprise#122669
Colombian electronic invoice imports now keep the DIAN price amount as the actual unit price instead of dividing it by the base quantity. This prevents incorrect negative discounts on vendor bills when imported XML lines use quantities greater than one.
Original PR description
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price…
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal. Solution: Extract the basis_qty logic into a helper method so other localizations can override when needed. Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill. Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied. task-6215466 Forward-Port-Of: odoo/enterprise#124400 Forward-Port-Of: odoo/enterprise#122313
Fixed an issue where Uruguayan e-Ticket credit notes for original tickets totaling 0.00 could be rejected by the tax authority because a required zero-value reference was omitted. The system now keeps that mandatory value in the electronic document, improving compliance and avoiding failed submissions for these edge cases.
Original PR description
Problem: When generating an e-Ticket Credit Note for an original e-Ticket with a total amount of 0.00, the XML cleanup mechanism removes reference fields whose value is 0.00. As a result, the credit note is rejected by DGI with: "CODE 31: En línea de Referencia 1 si NO IndGlobal = 1 deben existir TpoDocRef, Serie, NroCFERef, MntCFERef, TpoMonedaRef." Solution: Ensure that MntCFERef is sent even if the value is 0.00. opw-6378783 Forward-Port-Of: odoo/enterprise#124377 Forward-Port-Of: odoo/enterprise#124354
4 changes
Resolved issues and error corrections
Mobile users can now see and use the “Upload a PDF & sign” button in the Sign app. This fixes a display issue that prevented users on smaller screens from starting a PDF signing flow.
Original PR description
Issue: ---------------------------------------- When opening the Sign app on mobile, the "Upload a PDF & sign" button doesn't appear. Cause: ---------------------------------------- The Sign buttons are in a `<t t-if="!env.isSmall">`. So if the screen has a width smaller than 767.98px, the buttons aren't displayed. Solution: ---------------------------------------- Remove the `t-if`. It works fine without it. Did not remove the `<t>` for stability. opw-6377211
The bank reconciliation report now shows all unreconciled transactions up to the selected date, not just those from the latest bank statement. This helps finance teams get a complete view of pending reconciliation work and avoid missing older transactions.
Original PR description
The reconciliation report lists only the unreconciled transactions from the last statement instead of all of them Steps: - Create 4 statements with one statement line each with different dates - Go to the reconciliation report (via the three dot menu on bank journal kanban card) - select date as Today -> only the line from the last statement is displayed opw-6250370
This fix ensures the barcode app keeps only one delivery line selected when workers switch between packaged and unpackaged products. It prevents confusing double selections during warehouse picking, reducing the risk of operational mistakes.
Original PR description
**Steps to reproduce:** - Enable "Move Entire Packages" setting on deliveries - Make a product A, that has a package P1, on hand qty of 1 - Make product B that don't have a package, but on hand qty…
**Steps to reproduce:** - Enable "Move Entire Packages" setting on deliveries - Make a product A, that has a package P1, on hand qty of 1 - Make product B that don't have a package, but on hand qty of 1 - Make a delivery that has both of those products, requested qty of 1 for both - Mark it as todo - Go to the barcode app, select the delivery - Select the line with product B - Select the line with product A --> The line with product B is not unselected **Why the fix:** When we have a mix of packaged products and products without a package on the same operation, they are handled separately. The products without a package are handled in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L388-L392 that calls https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1277-L1284 But as you can see, there are no mention of the selected package line, which is stored in **this.lastScanned.packageId**. As we do not touch this variable, the selected package line stays selected. The same is true for the other way around, when we select a package line we call https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L394-L398 This function does not care for the **selectedLineVirtualId** which represents the selected line without a package. To avoid this and make it so that only one line is selected even if they have different package, we now set the corresponding value to false to unselect the other line in all situation. This is basically how it's done in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1202-L1208 to unselect every line regardless of packages. opw-6266203
Delivery guides can now be printed correctly when a kit includes components measured differently from the kit product. The change prevents pricing errors by using the component product price when the delivered component differs from the sale order item.
Original PR description
When a kit is delivered, each component move is linked to the kit's sale order line. Pricing the delivery guide in "sale order" mode converted the component quantity into the kit's sale UoM. For a component sold in a different UoM category than the kit, this cross-category conversion raises a UserError. Steps to reproduce: - Create a BoM for a kit product with a component in a different UoM category - Create a customer with Delivery Guide Price = "From Sale Order" - Sold the kit in a sale order and deliver it - On the delivery, print the delivery guide -> error This fix makes the guide price for a component move to be "product" if the component's product is different from the related sale line product, avoiding the cross-category UoM conversion. opw-6327895