Daily updates from Odoo
Monday, September 29, 2025
207 changes
Resolved issues and error corrections
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