Monday, September 29, 2025
30 changes · 18.0
New functionality added to Odoo
Adds a new connector to import orders from multiple TikTok Shop or Tokopedia Shop accounts into Odoo. It matches orders to products, supports both seller-fulfilled and platform-fulfilled flows, and can synchronize delivery and stock information for seller-fulfilled orders.
Original PR description
- Import orders from multiple accounts - Orders are matched with Odoo products based on their internal reference (item_id or SKU ID in Tokopedia | Shop) - Support for both Fulfillment by TikTok/Tokopedia | Shop (FBT), Fulfillment by Seller (FBS): - FBT: Importing the completed orders - FBS: Delivery information is fetched from Tokopedia | Shop, track and synchronize the stock level to Tokopedia | Shop Task ID: 3690836
This adds support for carrying Taiwan ECPay e-invoice details from point-of-sale and online checkout through to invoice creation. It helps Taiwanese businesses capture the right invoice information during sales, reducing manual follow-up and improving compliance workflows.
Original PR description
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
Enhancements to existing features
The tax search now includes the configured tax amount, so users can quickly find taxes by entering a percentage or fixed amount in the search bar. This makes tax setup and review faster, especially for companies with many tax records.
Original PR description
This commit improves the usability of the tax search view by including the `amount` field. Users can filter taxes based on their configured percentage or amount directly from the search bar. task-5088050 Forward-Port-Of: odoo/odoo#227131
The update aligns enterprise localization tests with a recent change that adds delivery party information to UBL electronic documents. This helps ensure electronic invoice and related document checks remain reliable for affected localizations, especially Peru.
Original PR description
The community commit introduced the `<cac:DeliveryParty>` element under `<cac:Delivery>` in UBL XML. This enterprise commit improves test coverage for the element and updates existing UBL tests that were failing due to the additional tag. ---- Community PR: odoo/odoo#223756 task-5022404
This update improves how borders are carried into emails so images and styled content appear as intended. It helps ensure email designs remain visually consistent for recipients across email clients.
Original PR description
This commit ports the following fixes to `convert_inline` of `mail`: - https://github.com/odoo/odoo/commit/8923f32426fc64e90db249fad47d7ca7e338adef [FIX] web_editor: adapt border-style value based on border widths - https://github.com/odoo/odoo/commit/7de31c6261d2fe9f58b0c6cb635977e77eecd9d6 [FIX] web_editor: ensure image border visible in emails --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Applicants who schedule their own interview through the Appointment app are now correctly linked to their recruitment record. This ensures the applicant profile shows the right meeting count, helping recruiters track interviews accurately.
Original PR description
In this bug, the number of interview meeting of applicant is not shown correctly. The meetings which are scheduled by applicant in appointment app, are not take into account. To reproduce: 1- Create a db with appointment and recruitment installed. 2- Create a new job position, with email template to let applicant schedule a meeting. 3- Move forward the applicant to interviewing stage, and use the link provided to the applicant to set an appointment. 4- Open applicant. As you see, the smart button is showing: `No Meeting` This bug, is result of not setting `applicant_id` in the `calender.event` when the event is set by the applicant. When db user schedules the event, the context has a default value `default_applicant_id`, but this is missing for the case when applicant sets the interview themsevles resulting `applicant_id` to be empty. opw-4784349
This fix ensures missing warehouse locations are created before point of sale setup triggers related stock operations. It helps prevent installation or upgrade failures for databases with incomplete warehouse configuration, improving reliability during upgrades.
Original PR description
DBs and upgrades are failing [here](https://github.com/odoo/odoo/blob/9ace6d7da6ae826ccace15fc21a262463c3e3886/addons/stock/models/stock_warehouse.py#L387) when `values["default_location_src_id"]` or…
DBs and upgrades are failing [here](https://github.com/odoo/odoo/blob/9ace6d7da6ae826ccace15fc21a262463c3e3886/addons/stock/models/stock_warehouse.py#L387) when `values["default_location_src_id"]` or `values["default_location_dest_id"]` are `False`. This happens when some `stock.warehouse` have null `stock.picking.type` references so the picking types have to be created, but the `stock.warehouse` fields use to compute `stock_picking_type` `default_location_dest_id` and `default_location_src_id` are null. To avoid this, we make sure the missing location of all `stock.warehouse` are created before creating the `stock.picking.type`.
The problem happens from 17.3 and later on, because the concerned fields are required only from this version.
`stock.picking.type.default_location_dest_id` [definition](https://github.com/odoo/odoo/blob/e1fb54cb3d5db9c906946fa11ff49c1ca86d3722/addons/stock/models/stock_picking.py#L37)
### To reproduce:
1. install odoo { 17.3 - ... } with stock,mrp
2. Nullify the following fields in some warehouse:
  Stock After Manufacturing Location
  Picking Before Manufacturing Location
  Stock After Manufacturing Operation Type
  Picking Before Manufacturing Operation Type
To view the fields:
  Developper mode
  Settings > Warehouse > Multi-Step Routes: True
  Warehouse > SomeWarehouse > Technical Information
To nullify the fields:
  Rules: Archived + Operation Type contains 'Pick Components' > Delete
  Operation Types: Archived > Delete 'Pick Components' & 'Store Finished Products'
  Locations: Archived > Delete 'WH/Pre-Production' & 'WH/Post-Production'
(or `update stock_warehouse set pbm_type_id=null,pbm_loc_id=null,sam_type_id=null,sam_loc_id=null` with sql)
3. install point_of_sale
Linked pr: https://github.com/odoo/upgrade/pull/8360
Related traceback group: https://upgrade.odoo.com/odoo/tbg/877/upgrade.request/3051298/tbg/877/3051298/upgrade.request/3051298/tbg/877
```
vval_3051298> select id,pbm_type_id,pbm_loc_id,sam_type_id,sam_loc_id from stock_warehouse order by id
+----+-------------+------------+-------------+------------+
| id | pbm_type_id | pbm_loc_id | sam_type_id | sam_loc_id |
|----+-------------+------------+-------------+------------|
| 1 | 36 | 64 | 37 | 65 |
| 2 | 39 | 66 | 40 | 67 |
| 4 | 42 | 68 | 43 | 69 |
| 5 | 45 | 70 | 46 | 71 |
| 6 | <null> | <null> | <null> | <null> |
+----+-------------+------------+-------------+------------+
```
[upg-3051298](https://upgrade.odoo.com/odoo/upgrade.request/3051298)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prCorrected the Italian e-invoicing XML so linked invoice dates use the official field name required by the tax authority validator. This prevents affected invoices with customer references from being rejected due to an invalid date element.
Original PR description
The name for the date in DatiFattureCollegate (56e08bb091d39a18ea1c8e7699321b953a8823e1) is wrong. It is not DataDocumento but Data as per https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiGenerali/DatiFattureCollegate/Data/18
How to reproduce the issue:
- With l10n_it, create an invoice and fill the customer reference field.
- Generate the xml and validate through https://fex-app.com/servizi/verifica
- The following error related to the date happens: E-invoicing (Italy) La fattura elettronica è stata rifiutata dall'SdI. File non conforme al formato : Invalid content was found starting with element 'DataDocumento'. One of '{Data, NumItem, CodiceCommessaConvenzione, CodiceCUP, CodiceCIG}' is expected. riga: 80 - colonna: 24
opw-5082016
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prPayment terminal messages added to Point of Sale receipts now print at a readable size. This improves receipt clarity for customers and staff while keeping the on-screen receipt display consistent.
Original PR description
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a…
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a receipt printer. This is because the font size styling was in the wrong place, and in the UI it fell back to bootstrap's CSS which makes it fairly large, but html2canvas renders it very small. After this commit, the problem is fixed by moving the font size styling to the correct place to apply to the text. In the UI, the text is actually slightly smaller than before, but when printed it is bigger and consistent with the UI. Before/After (UI): <img width="346" height="325" alt="image" src="https://github.com/user-attachments/assets/0a9dceb3-e224-473f-b02f-ff94b81b0a8d" /> <img width="349" height="319" alt="image" src="https://github.com/user-attachments/assets/b096172a-4a98-4249-a5d4-00c8a46ab4d0" /> Before/After (Receipt): <img width="513" height="503" alt="image" src="https://github.com/user-attachments/assets/e1d6ba27-1ff6-4853-b617-1c010857f1eb" /> <img width="516" height="528" alt="image" src="https://github.com/user-attachments/assets/82cb2431-707f-40c7-a9a5-f439d3934e16" /> task-5116506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228775
Fixes an issue in subscriptions where invoice section information for combo products could be overwritten or filled with unnecessary values. This helps keep generated invoices accurate and clearly organized for customers.
Original PR description
This commit improve fix of PR https://github.com/odoo/enterprise/pull/90989 to avoid overriding right combo section values and avoid setting unnecessary values on the section. opw-5069278
This fixes when French POS audit hashes are created so they use the complete finalized order information. It prevents legitimate point-of-sale orders from being incorrectly flagged as altered during inalterability checks, improving confidence in compliance reporting.
Original PR description
Description of the issue/feature this PR addresses:
Starting from version 18.0, inalterability hashes in the FR localization are sometimes calculated with incomplete data, leading to incorrect `l10n_fr_hash`. Related orders are then wrongly flagged as altered when running the POS Inalterability Check.
Current behavior before PR:
When you post a POS order and a related draft order exists, Odoo updates the existing order with the new vals. Because `{'state': 'paid'}` is amongst the new vals, it triggers the generation of the `l10n_fr_hash` before the order is fully processed. For instance, the hash will be generated before a new payment line is added for change with `_process_payment_lines()`.
Desired behavior after PR is merged:
The hash should be generated at the end of the order processing, with the final write in `action_pos_order_paid()`.Task lists now keep the allocated hours field visible and editable even when the value is 0. This makes it easier for users to update multiple tasks in bulk without being blocked by hidden empty-hour cells.
Original PR description
Before this commit, when the user would like to edit the allocated hours field of multiple tasks inside the list view, he cannot when the allocated hours is equal to 0. The reason is because the cell is hidden once the value is equal to 0. This commit makes that field is always editable in the list view of tasks even if the value is 0. task-5093288 Forward-Port-Of: odoo/odoo#228188
This fixes an issue where certain Dutch organization identification numbers were assigned the wrong electronic invoice scheme code. The correction helps ensure BIS3 and NLCIUS electronic invoices are generated with the expected identifier, reducing validation or exchange issues.
Original PR description
We previously [1] fixed the EAS that was incorrectly set to 0106 instead of 0190 in case of OIN (lenght = 20). This fix was overriden in the backport of the 19.0 dict helpers [2]. [1]: https://github.com/odoo/odoo/pull/219424 [2]: https://github.com/odoo/odoo/pull/215610 opw-5107445
The point of sale now makes sure all needed records are created and connected before continuing with setup. This helps prevent setup issues that could disrupt checkout or related workflows.
Original PR description
This commit change the behavior of loadData to ensure that all records are linked & created before calling setup method of each of them. related task: 4922193
This update corrects how the web test mock server handles creating records linked through many-to-many fields. It prevents errors in test scenarios, helping ensure the web interface behaves reliably when validating related-record workflows.
Original PR description
Before this commit, using CREATE Command on a many2many field would result in an error. This is because upon record creation the inverse field would be set to the single id, which is incorrect for a many2many field. This commit fixes the issue by setting the inverse field of a many2many to a list containing the new id.
This fixes an issue where packaging information could be missing when creating products with only one variant. It ensures product packaging is correctly carried over, helping users avoid incomplete product setup and related sales or inventory confusion.
Original PR description
e158730ba16e898a13dd9a98ed96fa30fa95ab6f recently fixed a situation where one-variant products had duplicated packagings. In the aforementioned commit, we concluded that the logic to write (again) the templates values for variant-stored fields was useless because already applied to the generated variants. Nevertheless, while trying to remove in master this logic, we noticed that those varlues are only applied to variants of templates having at least one attribute line, whose creation will trigger the variants creation. This commit therefore partially reverts the previous commit, bringing back the first solution that is still the best approach in the end. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales orders now use the loyalty reward description as the line description for free products, instead of showing the underlying product name. This makes customer-facing order lines clearer and keeps sales behavior consistent with the point of sale experience.
Original PR description
Currently, the reward's product name is used as the SOL name for the free product, which can be confusing. **To reproduce this issue:** 1) Install the sale_loyalty module. 2) Create a loyalty program…
Currently, the reward's product name is used as the SOL name for the free product, which can be confusing. **To reproduce this issue:** 1) Install the sale_loyalty module. 2) Create a loyalty program that grants a free product. 3) Manually update the reward's description. 4) Create a SO with a SOL containing that product 5) Apply the reward and observe the behavior. **Issue / Cause:** - The free product's description is taken from the reward product's name instead of the manually updated description. - This is incorrect because, in the point of sale, the name is taken from the reward's `discount_line_product_id` rather than the `reward_product_ids`. https://github.com/odoo/odoo/blob/0abdcd9ef6ad3fc932dc0eb46d8aa973b00c34c2/addons/pos_loyalty/static/src/overrides/models/pos_order.js#L1162 **Solution:** To resolve this inconsistent behavior, the free product name in the sale order line will now be taken from discount_line_product_id. opw-4982774 Forward-Port-Of: odoo/odoo#223755
Arabic invoice reports for Saudi Arabia now display the description column with consistent alignment. This makes invoice line descriptions easier to read and improves the presentation of localized invoices.
Original PR description
**Steps to reproduce:** 1. Install l10n_gcc_invoice. 2. Add and Switch to a Saudi Arabia company. 3. Select boxed layout (or keep any layout). 4. Create and print an invoice. **Issue:** - The…
**Steps to reproduce:** 1. Install l10n_gcc_invoice. 2. Add and Switch to a Saudi Arabia company. 3. Select boxed layout (or keep any layout). 4. Create and print an invoice. **Issue:** - The description column is misaligned in the Arabic invoice report. According to Saudi localization, it should be aligned to the left for better readability. The current alignment makes Arabic text inconvenient to read. **Cause:** - Other columns (e.g., quantity, taxes) already use the `text-end` class, but the description column has no alignment class, causing inconsistent layout and misalignment. **Solution:** - Added the `text-end` class to the description column to ensure proper alignment and consistent readability in Arabic invoice reports. **Before FIX:** <img width="831" height="329" alt="image" src="https://github.com/user-attachments/assets/857f9f7f-d930-4c73-b2fa-eacd7a153ea3" /> **After FIX** <img width="788" height="354" alt="image" src="https://github.com/user-attachments/assets/929acdb1-bb13-4e1e-829c-8fdbe18334a4" /> **opw-5087770**
The payment registration flow now checks the bank account actually selected by the user, not only the account from the original bill. This prevents an incorrect warning from appearing when a trusted bank account is manually selected for SEPA vendor payments.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. * added testcase for the same in account_iso20022 [#95124](https://github.com/odoo/enterprise/pull/95124) opw-5059740
The forum page cover block is now editable in the website builder. This restores normal content editing for website managers and prevents a broken editing experience on the forum landing page.
Original PR description
Steps to reproduce: - Go to the "/forum" page and click "Edit". - Click the "s_cover" block. - Bug: the snippet is not editable. The cover snippet contains a link rendered with "t-attf-href", which makes the website builder refuse to mark the block as editable. This commit adds "t-ignore="True"" on the "oe_structure" so the branding stops before reaching the link and the snippet becomes editable again. task-5095234
The SEPA payment flow now checks the bank account actually selected by the user, not only the account originally linked to the bill. This prevents an incorrect warning from appearing when a trusted bank account is manually selected, reducing confusion during vendor payments.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. opw-5059740
Portal users can once again create project tasks by sending an email to a project alias. This restores an expected workflow that was unintentionally blocked by a recent safety change, reducing disruption for teams using email-based task intake.
Original PR description
The new safety belt introduced in 745f3accaf775550294d6f1bf562a0dcc15f7a08 made it impossible for portal users to create tasks by sending emails to the project alias. @moduon MT-11332 Forward-Port-Of: odoo/odoo#228009 Forward-Port-Of: odoo/odoo#225321
Fixes an error that could occur when users viewed the General Ledger from the Trial Balance while multiple companies were selected. This improves reliability for accounting users working across companies, especially when some account codes are hidden.
Original PR description
**Issue** When multiple companies are selected and Developer Mode is enabled, clicking "View General Ledger" for an account in the Trial Balance leads to a traceback. This affects accounts whose code is hidden. **Steps to Reproduce** 1. Go to Accounting > Reporting > Trial Balance. 2. Select multiple companies. 3. Click on an account where the account code is not visible. 4. From the three-dot menu, select "View General Ledger". 5. Observe the traceback error. **Root Cause** The error occurs because the `AccountReportSearchBar` component expects a string `initialQuery` prop, but in the multi-company scenario with developer mode enabled, the value passed can be `undefined` or non-string. Owl's strict prop validation then throws an `OwlError`, leading to the traceback. **Fix** Ensure that `initialQuery` is always a string when passed to `AccountReportSearchBar`. Opw-5050843
Credit notes created after a down payment now include the expected cost reversal entries. This keeps inventory valuation and accounting reports accurate when customers are refunded after partial invoicing.
Original PR description
**Problem:** When we do a downpayment on an invoice then pay the rest and do a credit note, the credit note does not reverse the cogs **Steps to reproduce:** - create a storable product invoiced on…
**Problem:** When we do a downpayment on an invoice then pay the rest and do a credit note, the credit note does not reverse the cogs **Steps to reproduce:** - create a storable product invoiced on ordered quantity - set the category of the product as avco and "inventory valuation" of the category as automated - set an onhand quantity and a positive cost - create a SO for 1 quantity of this product and confirm - click on create invoice, select downpayment percentage and 25% - click on create draft and confirm it - click on create invoice, select regular, create draft - confirm and select credit note - write something in the reason field and click on reserve - confirm it **Current behavior:** if you open the "Journal Items" page of the credit note you'll see that there is no line revresing the cogs (there would be if we didn't do a downpayment but invoiced all at once) **Expected behavior:** There should be: - A line crediting "600000 Expenses" (or the account that was debited for the cogs on the original invoice) with the amount being the cost of your product. - A line debiting "110300 stock interim (delivered)"(or the account that was credited for the cogs on the original invoice) with the amount being the cost of your product. **Cause of the issue:** Since this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 (slightly modfified for efficieny reasons by this commit https://github.com/odoo/odoo/commit/4f9c52c03c65a497937053530e8d6c775d305e35), when _stock_account_prepare_anglo_saxon_out_lines_vals is called on the account move (the credit note) it calls _get_anglo_saxon_price_ctx. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/account_move.py#L114 One of the invoice lines of the account move is linked via sale_line_ids attribute to a sale order line that is a downpayment. As a consequence, inside _get_anglo_saxon_price_ctx, move_is_downpayment will be populated with this line. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L136-L139 Then _stock_account_prepare_anglo_saxon_out_lines_vals calls _stock_account_get_anglo_saxon_price_unit. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/account_move.py#L131 Inside this method, because move_is_downpayment is populated, is_line_reversing will stay false https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L163-L164 As a consequence, - qty_to_invoice will become - qty_to_invoice - account_move will be populated - therefore posted_cogs will be populated https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L166-L174 So _compute average price will be called with a qty_invoiced of 1 instead of 0 and a qty_to_invoice of -1 instead of 1. So it will return 0 instead of the cost of the product because "missing" will be negative. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/product.py#L915 **fix** The use case of this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 is this one : - SO for qty of 10 (product invoiced on delivered qty). - 100% downpayment. - deliver 6. - invoice. In that case the invoice is actually a credit note but it still has to include the cogs (not reversed), so move_is_downpayment needs to be populated However in our use case the cogs has to be reversed (so move_is_downpayment has to be None). One difference between those two use case is that in our use case the account move has a reversed_entry_id. opw-5041783
This fixes a remaining source of inconsistent automated test results in Web Studio's rename flow. It helps keep quality checks stable so development and release validation are less likely to be delayed by false failures.
Original PR description
Similar to https://github.com/odoo/enterprise/commit/5574c52df8794b3f23d385a670cac8fb5355e229 There was still one indeterminism remaining runbot-232572
Fixes a checkout issue where shoppers could choose a free reward product from a coupon offer but it was not added to their cart. This ensures promotional coupons with multiple eligible reward products work as expected, reducing customer frustration and checkout failures.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a coupon program with a free product reward using a product tag; 2. generate coupons & copy a coupon code; 3. have 2 or more products with the tag; 4. go to /shop & add any product to your cart; 5. go to checkout; 6. apply coupon code; 7. select a free product; 8. click "Use". Issue ----- Product isn't added to the cart. Cause ----- On forward porting a fix for a similar issue in bb92ba5fbba94, it accidentally checks for the `product_id` in `request.env` instead of `request.env.context`. As no `product_id` is found, no product is added. Solution -------- Check `request.env.context` instead of `request.env`. opw-4979939
The Spanish Mod 349 tax report audit view now correctly displays the transactions behind the intracommunity operations summary line. This helps accounting users verify reported amounts and reduces the risk of unclear or incomplete tax report reviews.
Original PR description
Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) - Audit line 'Importe de las operaciones intracomunitarias' Issue: No line will be shown This occurs because the system will allow auditing the line, since the report line is defined as aggregation of sublines, however those sublines are all custom so we should provide a custom domain to retrieve the relevant lines opw-4752813 Forward-Port-Of: odoo/enterprise#84633
The Belgian POS black box connection now avoids an extra device read that could cause delays. This reduces the chance of timeout errors during point-of-sale operations, helping transactions run more reliably.
Original PR description
This commit is a backport of some parts of odoo/enterprise#93614. The goal is to ensure that we don't read too many different times from the serial port, as each read has a timeout of 3 seconds: if 2 read fail, we exceed the longpolling's timeout. Task: 5116854 Forward-Port-Of: odoo/enterprise#95635
Odoo now shows a clear validation message when a bank journal check number is too large, instead of failing with a technical server error. This helps accounting users understand and correct the value without needing technical support.
Original PR description
**Issue** When trying to set a very large value as *Next Check Number* in a Bank Journal, Odoo raises a low-level `RPC_ERROR` caused by a PostgreSQL `integer out of range` error. This results in a technical traceback instead of a clear message to the user. **Steps to Reproduce** 1. Go to *Accounting > Configuration > Journals* 2. Open the Bank Journal 3. Go to the *Outgoing Payments* tab 4. Enable *Manual Numbering* 5. Set *Next Check Number* to `2147483648` **Root Cause** The field `ir.sequence.number_next` is stored as an integer in the ORM. Any value greater than `2,147,483,647` (max signed 32-bit integer) causes PostgreSQL to raise an overflow error when saving. Since the error occurs deep in the ORM write call, the user only sees a generic RPC error without explanation. Opw-5042096 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of sale orders in Spain now automatically retry the earlier failed TicketBAI submission when a new order is paid. This helps prevent one failed submission from blocking later orders and reduces manual recovery work for staff.
Original PR description
Currently, the post failure of a single pos order can easily cause a backlog of more unposted orders since new orders will not be posted until the chain head is posted. Steps to reproduce ----- 1. Validate a pos order and have the TicketBAI post fail 2. Validate another pos order 3. The post for the second order is never attempted Cause ----- `_check_can_post()` ensures that new orders are not posted if the chain head was not posted successfully. During normal operation, it is common for many new orders to be paid before the user has a chance to manually retry the chain head post in the backend, causing a backlog of unposted orders. Solution ----- During `action_pos_order_paid()` retry the chain head post if is not sent. opw-4669823