Wednesday, November 5, 2025
30 changes · 19.0
Enhancements to existing features
This change adds a default set of attendance rules so employee attendances can be created even when no ruleset was previously defined. It includes rules for overtime and non-working days, helping avoid setup issues and ensuring attendance records work more smoothly.
Original PR description
## PR Purpose It's impossible to create an attendance for an employee without a ruleset. To solve this problem, this PR adds a default ruleset with 2 rules: one for overtime, and another one for non working days. Those data are the same as the data added in the upgrade/migrations/hr_attendance/saas~18.5.2.0 post-migrate script. [Task#5082628](https://www.odoo.com/odoo/all-tasks/5082628) [Community#228352](https://github.com/odoo/odoo/pull/228352) [Upgrade#8684](https://github.com/odoo/upgrade/pull/8684)
This change adds a default overtime ruleset for employee attendance records. It ensures attendances can be created even when no custom ruleset has been configured, preventing a setup issue and making the feature work out of the box.
Original PR description
## PR Purpose It's impossible to create an attendance for an employee without a ruleset. To solve this problem, this PR adds a default ruleset with 2 rules: one for overtime, and another one for non working days. Those data are the same as the data added in the upgrade/migrations/hr_attendance/saas~18.5.2.0 post-migrate script. [Task#5082628](https://www.odoo.com/odoo/all-tasks/5082628) [Enterprise#95421](https://github.com/odoo/enterprise/pull/95421) [Upgrade#8684](https://github.com/odoo/upgrade/pull/8684)
This change adds a queue for blackbox messages so the Point of Sale can send certain requests without waiting for an immediate response. It improves speed and reliability for operations like pro forma sales, helping staff continue working more smoothly even when the blackbox is busy.
Original PR description
In this commit, we introduce a queuing mechanism for blackbox messages to make all interactions with the blackbox faster and more reliable. This is particularly useful for messages that do not require the response from the blackbox to continue the workflow such as pro forma sales messages. Forward-Port-Of: odoo/enterprise#97293 Forward-Port-Of: odoo/enterprise#90747
Resolved issues and error corrections
This change prevents a product added through a combo from being mixed up with the same product added separately on a sales order. As a result, the correct line is created and prices are no longer incorrectly merged, avoiding billing errors.
Original PR description
Steps: - create a product with attributes of create_variant=never - set variant selection to order grid entry - add this product as a combo choice and set extra_price>1 - In sale order form first add the new combo product with the previously created product - add the new product with same selection of attribute values as combo Issue: - The separately added product should create a new line, but since it was added as a part of the combo, the product's price is summed with extra price and added to the combo itself Cause: - the grid field that is responsible for adding product using product matrix does not filter combo lines Fix: - added filter for combo lines when matrix opens and saves opw-5164789 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234102
Withholding invoices now include the VAT percentage correctly in the Nilvera e-invoice data. This fixes the VAT amount display in the PDF, so customers see the right tax information on their invoices.
Original PR description
Before this commit: For withholding invoices, the VAT percentage was not included inside the <cac:TaxTotals> node, due to this, the VAT amount was not displayed in the PDF in Nilvera. After this commit: The VAT amount is shown correctly in the <cbc:Percent> node inside the <cac:TaxTotals> node and percent amount appears correctly in the PDF. task-5225600 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234063 Forward-Port-Of: odoo/odoo#233929
This change ensures that when a component line is removed in the subcontracting wizard, it is fully deleted instead of being left behind as an invisible record. This prevents confusing leftover entries in inventory reports and keeps production data accurate.
Original PR description
Issue ----- Removing a line using the subcontracting wizard does not delete the line in DB, there is a "phantom" ML. Steps to reproduce ----- - Create a subcontracted product with 2 components - Add…
Issue ----- Removing a line using the subcontracting wizard does not delete the line in DB, there is a "phantom" ML. Steps to reproduce ----- - Create a subcontracted product with 2 components - Add one of each component in subcontractor's stock - Create a PO for the finished product and confirm it - Go to the production - Open the "Record components" wizard - Set quantity then remove the second line - Confirm production (don't update consumption) - Go to Inventory > Reporting > Moves History and remove the "Done" filter > There is a pending move in the report Cause ----- When saving the wizard's changes, we call a write on the production's `move_line_raw_ids` field to remove delete the line. The field is a simple compute, so we go through its' inverse method https://github.com/odoo/odoo/blob/be3a4283c383d187570f5a73f337030e6ae9d05c/addons/mrp_subcontracting/models/mrp_production.py#L34-L46 The problem is that we populate `line_by_product` using the values present in `move_line_raw_ids` from which we just removed the line. This means that when we do `move.move_line_ids = line_by_product.pop(move.product_id, self.env['stock.move.line'])` we replace the value of `move_line_ids` with only the remaining ones, which means we unlink the move line (*from the move*). Because the inverse field (`move_id` of the SML) is not set as `ondelete='cascade'`, the link is broken but the line remains in db. https://github.com/odoo/odoo/blob/f173c738b1adcf85a80eb641ad307b7cccf17294/odoo/fields.py#L4311-L4322 We cannot change the field to `ondelete='cascade'` as such a change would not be stable. Solution ----- Keep reference of the lines to be removed in order to delete them once `move_line_ids` has been updated. ----- Ticket: opw-4817397 Forward-Port-Of: odoo/odoo#234180 Forward-Port-Of: odoo/odoo#229310
We fixed an issue in the salary calculator that could increase the Salary field incorrectly when switching employees. The calculator now also handles employees with existing payslips properly, so the displayed figures are filled in and calculated as expected.
Original PR description
- fixed a bug where the value of `Salary` field gets incremented when selecting another employee instead of computing the correct value
- fixed a bug of wrong calculations when the employee has a generated payslip
- Steps to reproduce:
- create a payslip for the employee
- open the salary calculator and select this employee
- the values are wrong or not filled because the `salary_simulation` wasn't set correctly on the simulation version
- added `test_simulation_offer_with_existing_payslip` for the salary calculator
task-id: 5065138This fix removes Chinese yuan (CNY) from the currencies offered by PayPal payments in Odoo. As a result, customers will no longer reach a payment flow that PayPal cannot complete, avoiding failed invoice payments and confusion.
Original PR description
## Versions 18.0+ ## Issue No payment is possible with PayPal for invoices expressed in Chinese currency. ## Steps to reproduce **`account` app required** - Enable "CNY" currency via `Invoicing /…
## Versions
18.0+
## Issue
No payment is possible with PayPal for invoices expressed in Chinese currency.
## Steps to reproduce
**`account` app required**
- Enable "CNY" currency via `Invoicing / Configuration / Accounting / Currencies`;
- Install, setup and publish PayPal payment provider;
- Move to the Invoice app:
- Create a new invoice in "CNY" currency for any customer with at least 1 product;
- Confirm and click on the preview button:
- Click on the "Pay now" button then "Pay" button of the wizard.
## Cause
"CNY" currency is only supported for Chinese accounts and for transactions occurring in China. PayPal says:
> Please note that Chinese Renminbi (CNY) is supported as a payment currency (buyer currency) or settlement currency (holding currency) only for in-country PayPal accounts. If the settlement account is based outside of China, PayPal will convert the funds into the account’s primary currency using the applicable currency conversion rate, which includes a spread or fee.
opw-5071893
Forward-Port-Of: odoo/odoo#232092This update ensures that when someone signs a document while logged in as a different user, the system no longer uses the other user’s saved signature. It also adds a clear note in the signing certificate to show that the document was signed through another account, improving transparency and trust.
Original PR description
Before this commit, we allow to sign on behalf on another user but we should not fetch his saved signature. We want that when a user is signing from the account of another user: - we don't load the signature of the user (saved in the user profile) - we have a mention in the certificate that the document was signed via another user. task-5223975
This fix makes the email loop protection only count actual incoming emails, instead of also counting other message types. As a result, legitimate emails are less likely to be blocked by mistake when a thread includes non-email activity from the same sender.
Original PR description
When detecting loops with _detect_loop_sender if the count of these messages exceeds the LOOP_THRESHOLD, the next email from that user is blocked, even if the number of new emails alone hasn't yet crossed the threshold due to mail messages that are not email triggering the loop detection. This happens because it searches for messages in the mail.message model that share the same model name and author irrespective of the message type. To correct this, the function's search criteria must be modified to explicitly filter for messages where the message_type is set to 'email'. opw-5122962 Forward-Port-Of: odoo/odoo#232534 Forward-Port-Of: odoo/odoo#232026
This fix prevents quotation preview from crashing after a report has been customized in Studio. It ensures the portal preview uses the same data reference as the edited report, so users can continue reviewing quotations normally.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Edit the `sale.report_saleorder` report using `web_studio`. 2. Add the `amount_untaxed` field next to the "Untaxed Amount" subtitle. 3. Create or navigate to…
Versions -------- - 17.0+ Steps ----- 1. Edit the `sale.report_saleorder` report using `web_studio`. 2. Add the `amount_untaxed` field next to the "Untaxed Amount" subtitle. 3. Create or navigate to a quotation and click on the "Preview" action. Issue ----- A traceback occurs during the rendering of the `sale.sale_order_portal_template` template. ``` Error while render the template KeyError: 'doc' Template: sale.document_tax_totals Path: /t/t/tr/td[1]/span Node: <span t-field="doc.amount_untaxed"/> The error occurred while rendering the template sale.document_tax_totals and evaluating the following expression: <span t-field="doc.amount_untaxed"/> ``` Cause ----- In the `sale.report_saleorder_document` template, `doc` is used as the variable name for the current sale order. Consequently, the studio edit uses this variable name to modify the `sale.document_tax_totals` template called within `sale.report_saleorder_document`. However, the `sale.sale_order_portal_template` template, used for the portal preview, also calls `sale.document_tax_totals` but uses `sale_order` as the variable name for the current order. Solution -------- Add an alias `doc` for `sale_order` during the rendering of `sale.document_tax_totals` when called in the portal report preview. opw-5136553 Forward-Port-Of: odoo/odoo#233755
Typing or pasting calculated dates into datetime fields now behaves correctly when the field loses focus. This fixes an issue where the wrong field elements were being handled, causing the edit button to reappear unexpectedly.
Original PR description
How to reproduce ================ Write an operation or calculation in datetime field like +1d or +=1d or copy/paste a value in field. As the focus is lost, button reappears in the field. Then, the getInputs method in useDateTimePicker hook must (as this name suggests it) return input elements. The fix ======= We filter on tagName === 'input' elements Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents an error when changing the sales order linked to a delivery. It also keeps related delivery items aligned with the new sales order so the records stay consistent and easier to manage.
Original PR description
Steps to reproduce: - Create a Sale Order with at least one product line & confirm it. - Open the delivery - Change the picking's SO to another one Issue: A traceback will happen, as the `Command` expects an id, not a record Aside from the traceback, we need to think of what it implies to change the SO on a picking like this. If the move have a sale_line_id, it doesn't make sense to have some still related to one SO while the picking itself is linked to another one. Now tries to do a basic matching of the moves based on their product within the newly set Sale Order. sentry-6921046230 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents an error in the German fiscal certification flow when a POS order line is fully discounted. It ensures orders with a 100% discount are processed correctly, avoiding checkout interruptions for affected businesses.
Original PR description
Since this PR (https://github.com/odoo/enterprise/issues/83300), a division by zero error in Fiskaly POS certification when an order line has a 100% discount by directly setting gross_discount to price_subtotal_incl. Before this fix, applying a full discount led to a division by zero error : ``` File "/home/odoo/src/enterprise/19.0/l10n_de_pos_cert/models/pos_order_line.py", line 48, in prepare_line_data gross_discount = float_repr(round(self.price_subtotal_incl / (1 - self.discount / 100), 2) - self.price_subtotal_incl, precision) ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~ ZeroDivisionError: float division by zero ```
This update corrects payroll export behavior so the fields chosen by the user are the ones included in the exported file. It prevents exports from falling back to incorrect default fields, making payroll data exports more reliable and accurate.
Original PR description
Since the introduction of payslip issues, the optional active fields were not correctly given back to the controller. This resulted in having the wrong default fields inside the export (not the ones selected). This commit fixes the issue by avoid using a proxy. task-5129681
This fix prevents the Point of Sale from crashing when an order is validated with a customer record missing required information. Instead of failing, the system now shows the proper warning and opens the customer form so the missing details can be completed.
Original PR description
Before this commit, when validating an order, if the selected contact was missing a required field, the PoS would crash instead of displaying the correct notification and opening the partner edit form. opw-5222040
This change prevents an error from appearing when a new IoT Box record is created after connecting a device. It ensures the box version is checked only after it has been properly set, improving reliability during setup.
Original PR description
In order to avoid a traceback when creating the IoT Box record after connection, we need to ensure the version is set, before checking whether the first character is a "W".
Fixed an issue where scanning a barcode in the product view could trigger a search using only part of the code. This ensures the full barcode is used, making scans more reliable and reducing incorrect matches.
Original PR description
Issue ----- When scanning a barcode in the product view, the search is made using only part of the barcode. Steps to reproduce ----- - Open the product view - Scan a barcode (eg 1234567890) > The search might only contain 12345678, 123456 or actually the full barcode Cause ----- When scanning a barcode, we receive all of the barcode characters followed by newline. When we receive the newline, we select the first item in the dropdown. The problem is that the search input changed but it hasn't been reflected yet in the items (a rendering is scheduled but hasn't been applied to the DOM yet). ----- Ticket: opw-4874425 Forward-Port-Of: odoo/odoo#234207 Forward-Port-Of: odoo/odoo#232270
Users can now create invoices linked to Point of Sale orders even when the invoice is still in draft, instead of being blocked. The system shows a warning to guide the user, which helps in countries where invoices must be adjusted before being sent to the tax authority.
Original PR description
After this commit, it becomes possible to make an invoice linked to a PoS order draft, showing only a warning notification instead of blocking the action. This is required in some localizations where invoices must be modified before being sent to the government. opw-5218715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234041 Forward-Port-Of: odoo/odoo#233649
The attendance kiosk now keeps the barcode scanner available when the kiosk is set to “Barcode / RFID and Manual Selection.” This fixes a bug that prevented scanning in that mode, so users can continue using the scanner as intended.
Original PR description
Issue: In this bug, barcode scanner is disabled in barcode_manual kiosk mode. To reproduce: 1- Create a db with `hr_attendance` installed 2- Set `Kiosk Mode` to `Barcode / RFID AND Manual Selection` 3- Open `Kiosk Mode`. As you see the scanner is disabled. `t-att-disabled` shouldn't be set to `barcode_manual` as it should not be disabled in `barcode_manual` mode. Also there is no need of `t-att-disabled` attribute at all as: https://github.com/odoo/odoo/blob/f6b430245b98fb55cac7c8303b7f5bd8a3e1c84e/addons/hr_attendance/static/src/public_kiosk/public_kiosk_app.xml#L113-L114 the `KioskBarcodeScanner` will not be mounted if the mode is manual. opw-5153954
This update prevents a crash when the system tries to check for PDF indexing support but the PDF library is not installed. It makes attachment processing more reliable by safely handling missing optional dependencies.
Original PR description
The call to `importlib.util.find_spec('pdfminer.high_level')` introduced by https://github.com/odoo/odoo/pull/230123 crashes when the module is not available. One has to check for `'pdfminer'` first, and then `'pdfminer.high_level'`.This fix ensures the work center’s hourly cost is correctly included when an operation is marked done directly from the status widget. As a result, project profitability and gross margin calculations now reflect the true cost of the work order in this common workflow.
Original PR description
This PR fixes the problem of adding the hourly cost of the work center when marking an operation as done from the status widget. To reproduce the bug: 1- Create a work center with an hourly cost > 0. 2- Create an MO with 1 operation in that work center, expected time > 0. 3- Create and set a project on the MO. 4- Make sure that project has an analytic account. 5- Mark the operation as done from the status widget. (click on it and choose done, don't use the start button) 6- Go to the analytic account of the project and check the gross margin. = No cost of the workorder was added. Now, this PR takes into account the duration of the WO first when marking it as done directly from the status widget. Task-5156286
Customers can no longer cancel a self-order once it has been sent to the kitchen display. This avoids situations where the order is removed in the backend but the kitchen team is not informed, helping prevent confusion and preparation mistakes.
Original PR description
Currently, it is possible to cancel orders that have been sent to the kitchen display. However when doing so, the kitchen displayd does not receive any information about the cancellation. Steps to reproduce: ------------------- - Modify restaurant and enable self ordering - Open self an place an order (not paid but sent to kitchen) - Go back to "My orders" and cancel it > Order is cancelled in backend but not in the kitchen display Why the fix: ------------ When an order is sent to the kitchen the only way to cancel it should be by going to the register. Therefore now, if an order is present on the kitchen display we will not show the cancel button. opw-5030223 Community: https://github.com/odoo/odoo/pull/229039 Forward-Port-Of: odoo/enterprise#98035 Forward-Port-Of: odoo/enterprise#95770
This update helps the system notice broken WebSocket connections much sooner when the network is slow or unstable. As a result, users are less likely to experience silent message delays or missed updates before the app reconnects.
Original PR description
When a TCP connection is not closed cleanly, it can take minutes to detect a closed WebSocket connection. During this time, no messages are received. This can happen in slow or unstable network conditions. Browsers do not expose WebSocket ping/pong mechanisms. To detect dead connections quickly, periodic application level messages are sent if no messages were either sent or received within a minute. This approach ensures quicker detection compared to relying on the OS TCP timeout, which is typically set to a high value. X-original-commit: d043e12 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234311 Forward-Port-Of: odoo/odoo#234275
This fix avoids a server error when a credit or debit note is sent to DGI and its original document is not a valid electronic invoice. Instead of failing with a traceback, Odoo now shows a clear message so the user can correct the document before resubmitting.
Original PR description
### Description of the issue/feature this PR addresses: When informing a Credit or Debit Note to DGI we always need to inform the related original document, Before this change is the related document…
### Description of the issue/feature this PR addresses:
When informing a Credit or Debit Note to DGI we always need to inform the related original document, Before this change is the related document is not a real CFE then will raise a traceback error
### Steps to reproduce:
1. Create an e-invoice and confirm in Odoo (without sending to DGI)
2. Create an e-credit note from the e-invoice created in (1) and confirm
3. Try to send the credit note to DGI
The result is a traceback:
```
RPC_ERROR
Odoo Server Error
Occured on 18.core.odoo.localhost on model account.move.send.wizard on 2025-10-21 20:47:48 GMT
Traceback (most recent call last):
File "/home/odoo/custom/odoo/odoo/http.py", line 2144, in _transactioning
return service_model.retrying(func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/service/model.py", line 156, in retrying
result = func()
^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 2111, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 2359, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/web/controllers/dataset.py", line 42, in call_button
action = call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/api.py", line 535, in call_kw
result = getattr(recs, name)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/account/wizard/account_move_send_wizard.py", line 294, in action_send_and_print
attachments = self._generate_and_send_invoices(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/account/models/account_move_send.py", line 719, in _generate_and_send_invoices
self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
File "/home/odoo/custom/odoo/addons/account/models/account_move_send.py", line 620, in _generate_invoice_documents
self._call_web_service_before_invoice_pdf_render(invoices_data_web_service)
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move_send.py", line 88, in _call_web_service_before_invoice_pdf_render
invoice._l10n_uy_edi_send()
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 813, in _l10n_uy_edi_send
request_data = move._l10n_uy_edi_prepare_req_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 787, in _l10n_uy_edi_prepare_req_data
xml_content = self._l10n_uy_edi_get_xml_content()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 773, in _l10n_uy_edi_get_xml_content
"referencia_lines": self._l10n_uy_edi_cfe_F_reference(),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 381, in _l10n_uy_edi_cfe_F_reference
cfe_serie, cfe_number = self.l10n_uy_edi_document_id._get_doc_parts(related_cfe)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/l10n_uy_edi_document.py", line 215, in _get_doc_parts
return re.findall(r"([A-Z]{1,2})[-]*([0-9]{1,8})", record.l10n_latam_document_number)[-1]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^
IndexError: list index out of range
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (http://18.core.odoo.localhost/web/assets/c15481d/web.assets_web.min.js:3162:163)
at XMLHttpRequest.<anonymous> (http://18.core.odoo.localhost/web/assets/c15481d/web.assets_web.min.js:3167:13)
```
### Desired behavior after PR is merged:
Now we ensure to show a proper message to the user to fix the problem: the original document should be a electronic one
<img width="1203" height="664" alt="after" src="https://github.com/user-attachments/assets/bb7b105e-12f0-4935-b6bc-37edb3bc3aca" />
References LATAM 1301 / ADHOC Task 54770
Forward-Port-Of: odoo/enterprise#90281This update corrects the invoice information sent to Chorus Pro so it matches French BIS3/Peppol requirements. It also removes an invalid attribute and renames one label to better match the wording used by Chorus Pro, reducing the risk of invoice rejection.
Original PR description
1. We didn't met one of the specific requirement of the BIS3 invoices to be sent through Chorus Pro. > The SIRET number for the final recipient, behind Chorus Pro should always be sent in the following tag: Invoice/cac:AccountingCustomerParty/PartyLegalEntity/CompanyID 2. One of the attributes of the CompanyID was set to schemeName which is not a valid attribute of the Peppol BIS3 specification. Fixed in 18.0+: https://github.com/odoo/odoo/commit/c3ae4b29c51c7b0cff11aac5f4bf4aab5fad16c9 task-none (possible opw-4972189, but might not be the only problem) Source: <img width="787" height="673" alt="image" src="https://github.com/user-attachments/assets/2a410fa8-572a-4738-aa5d-764e91271880" /> https://www.pagero.com/onboarding/aife/aife-en Forward-Port-Of: odoo/odoo#234139 Forward-Port-Of: odoo/odoo#229014
Customers can no longer cancel a self-order once it has been sent to the kitchen. This prevents the kitchen and the back office from getting out of sync and ensures cancellations are handled from the register instead.
Original PR description
Currently, it is possible to cancel orders that have been sent to the kitchen display. However when doing so, the kitchen displayd does not receive any information about the cancellation. Steps to reproduce: ------------------- - Modify restaurant and enable self ordering - Open self an place an order (not paid but sent to kitchen) - Go back to "My orders" and cancel it > Order is cancelled in backend but not in the kitchen display Why the fix: ------------ When an order is sent to the kitchen the only way to cancel it should be by going to the register. Therefore now, if an order is present on the kitchen display we will not show the cancel button. opw-5030223 Enterprise: https://github.com/odoo/enterprise/pull/95770 Forward-Port-Of: odoo/odoo#232989 Forward-Port-Of: odoo/odoo#229039
This change fixes a problem in the IoT driver certificate handling where date comparisons could fail because of mismatched time formats. As a result, certificate expiration checks now run reliably and avoid unexpected errors.
Original PR description
Before this commit, datetime.now() was compared to cert.not_valid_after_utc, leading to an error because we compare offset-naive and offset-aware datetimes After this commit, we set an offset-aware datetime.now() if we use not_valid_after_utc Issue introduced in #234005 opw-5237595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234446 Forward-Port-Of: odoo/odoo#234371
This change fixes an inventory issue where products delivered with a serial/lot number could be balanced against an empty stock record instead of the correct lot. As a result, stock counts stay accurate and later receipts with the right lot number no longer create mismatched quantities.
Original PR description
Uecase to reproduce: - Create a quant with a product and 10 lot A - Create a delivery order - Open barcode - In barcode, deliver the product with lot C Current behavior: You have 2 quants: - 10 lot A - -1 without lot Expected behavior: - 10 lot A - -1 lot C It happens because the code try to balance negative quant for lot/sn in a stack of quants without lot/sn for the product. However in this case the barcode create a quant without quantity and without lot. In this case the system wants to update it due to an incorrect condition. It's an issue since in later receit with the correct lot. The quant will never be balanced and it will result with - -1 without - 1 lot C Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232569 Forward-Port-Of: odoo/odoo#231853
We fixed an issue in Italian e-invoicing that could wrongly block invoices when ENASARCO was combined with other taxes. ENASARCO is now handled in line with its special status, so users can send invoices without unnecessary validation errors.
Original PR description
In the Italian localization, we validate that each invoice line has at most one tax per kind (VAT, withholding, pension fund). In Italy, a product cannot have more than one VAT tax. Also, the…
In the Italian localization, we validate that each invoice line has at most one tax per kind (VAT, withholding, pension fund). In Italy, a product cannot have more than one VAT tax. Also, the FatturaPA XML structure only allows global declarations for withholding and pension fund taxes — on the line level, it can only specify if those taxes apply, not which ones. To reflect this, we enforce one tax per kind per line. This validation was broken and recently fixed. However, ENASARCO is a special case: it acts both as a withholding and a pension fund tax. We added the Withholding flag recently (odoo/odoo#226968). In realistic cases (e.g., a line with VAT + withholding 23% RIT AG + ENASARCO), the validation fails and the user gets a blocking error in account.move.send. Since ENASARCO already has dedicated support through the AltriDatiGestionali tag on the line, we allow it to pass the check as if it were only a pension fund, restoring the previous behavior before we added the withholding flag. Some validation added and fields clear up in the tax editing phase, preventing invalid cases. Ticket [link](https://www.odoo.com/odoo/project.task/5154223) opw-5154223 Forward-Port-Of: odoo/odoo#233698 Forward-Port-Of: odoo/odoo#232140