Monday, August 18, 2025
27 changes · 18.0
Enhancements to existing features
The Belgian point-of-sale blackbox connection now retries checks and records clearer logs when identification fails. This helps reduce cases where the device is missed and gives support teams better information to diagnose issues.
Original PR description
This PR adds a retry mechanism and a logger to better identify and prevent cases where a blackbox isn't correctly identified as such
Resolved issues and error corrections
Account move imports with analytic allocations now avoid creating duplicate analytic entries. This keeps imported accounting records cleaner by ensuring the analytic entry is only created when the move is posted, while preserving the imported allocation details.
Original PR description
When importing an account move with analytic distribution, two analytic items are created, one at the creation of the move, and another when the move is posted. This happens because, when creating the move from an import, the line values passed include Commands to create analytic_line_ids, and not analytic distributions. Desired behavior: Only one analytic item should be created, and only when the move is posted. When the move is created, its lines' analytic distribution should be correctly filled based on the data imported. Solution: This commit unlinks the Analytic Lines created at move imports (removing the analytic_line_ids from moves at create/write), after the analytic distribution is set on the corresponding move line. task-4987799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an accounting issue where some batch payments could remain stuck instead of being marked as reconciled. The correction ensures payment matching status is recalculated when related payment information changes, improving reliability in bank reconciliation workflows involving early payment discounts.
Original PR description
In the goal of fixing the batch payments with EPD in the bank rec widget, we discovered another bug that was preventing the batch payments to change their state to "reconciled". This was due to some compute not being triggered again when one of its dependences did change (during another compute). task-4681366
Edited attendance records that were originally created as absences now update their status when check-in or check-out times are corrected. This prevents corrected attendances from continuing to appear as absences, reducing confusion for HR users.
Original PR description
### Steps to reproduce: - Run Absence detection cron - Navigate to the attendances got created in list view - Notice all of them are in red color - Modify the check in and check out dates to correct them as normal attendance - Notice the color didn't change in the view and it is still shows as red ### Cause: This is happening because color of the record is dependant on the check out mode, so if it is technical it means it is absence so we give it red color. https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/hr_attendance/models/hr_attendance.py#L84-L89 Also, the check out mode cannot be changed in any way. ### Fix: When updating the check out and check in time we check if the mode is technical we change it to manual. opw-4865524
The Attendance kiosk no longer incorrectly shows all check-in options for a company website using a public user without a password. This keeps the kiosk experience aligned with the company's configured Barcode/RFID setting and avoids confusing employees during check-in.
Original PR description
### Steps to reproduce: - Install Attendance and Website modules - Have a company 'Company A' - Create a new company 'Company B' - Set the Attendance kiosk mode to 'Barcode / RFID' for both companies…
### Steps to reproduce: - Install Attendance and Website modules - Have a company 'Company A' - Create a new company 'Company B' - Set the Attendance kiosk mode to 'Barcode / RFID' for both companies - Update all websites to be related to Company B - Go to the Kiosk mode for Company B - Notice it makes you choose between the 3 check in types while we only chose 'Barcode / RFID' ### Cause: When openning the kiosk mode it will check if the database is a trial one or if the user doesn't have a password and if so we assume that the database is a trial one. If it is a trial database we set the kiosk mode as 'settings' which shows all check in types when openning the kiosk mode. https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/hr_attendance/controllers/main.py#L101-L102 https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/hr_attendance/controllers/main.py#L185-L196 When creating a new company and set website for it we create a public user for this company and normally we don't set password for this user as no one is gonna login using it. ### Fix: We check if the user doesn't have a password and if he is not a public user. As we assume that if he is a public user he won't have a password anyways. opw-4916329
This fixes an issue where deliveries for kit products could fail after the customer invoice was already confirmed. Businesses can now invoice and deliver kits alongside their components without accounting reconciliation errors blocking the delivery process.
Original PR description
#### *mrp_account, purchase_{stock, mrp}, sale_{stock, mrp} ### Steps to reporduced: - In the settings enable: Automatic Accounting - Create 3 storable product: - COMP1, cost 1 $ - COMP2, cost 2 $ -…
#### *mrp_account, purchase_{stock, mrp}, sale_{stock, mrp}
### Steps to reporduced:
- In the settings enable: Automatic Accounting
- Create 3 storable product:
- COMP1, cost 1 $
- COMP2, cost 2 $
- KIT with a kit bom using COMP1 and COMP2, cost 3 $
- Modify the product category of all three products to:
- Costing Method: AVCO
- Inventory Valuation: Automated
- Create and confirm a sale order with 2 lines:
- 1 x KIT
- 1 x COMP2
- Create and confirm the associated invoive
- Try to validate the delivery
#### > UserError: You are trying to reconcile some entries that are already reconciled.
### Cause of the issue:
Validating the delivery will create stock valuation layers related to the associated stock moves — one for COMP1 and two for COMP2 — and then attempt to validate the corresponding accounting entries: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/stock_move.py#L283-L291
However, during this call, the SVLs are grouped by product_id: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/stock_valuation_layer.py#L88-L93
As a result, the first time we enter the loop, the accounting entries related to COMP01 will not be reconciled by the
`_stock_account_anglo_saxon_reconcile_valuation` call. This is because we restrict this call using the product COMP01. Therefore, we will not find the invoice needed to reconcile the outgoing moves here: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/account_move.py#L217-L219 (This happens because the related line of the invoice actually refers to the kit product, as the AMLs were not exploded like the stock moves.)
Now, the issue is that, since the AMLs were not reconciled, they will be added to the pool of lines to be reconciled later: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/stock_valuation_layer.py#L92-L100
However, the second time we enter the loop — for COMP02 — since COMP02 was sold by itself, there will be an account move line referring to this product on the invoice. The `_stock_account_anglo_saxon_reconcile_valuation` call, now restricted to COMP02, will therefore reconcile the AMLs for both COMP02 and COMP01 related to the kits (as it successfully finds the invoice to reconcile all outgoing moves). This is problematic because the AML related to COMP01 has now been reconciled, despite already having been added to the set of moves to be reconciled. This will raise an error during the second reconciliation attempt: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/account/models/account_move_line.py#L2379-L2380
### Fix:
In the case of kit products, the account move lines of the invoice refer to a different product than the stock valuation layers (because the stock move was exploded but not the AMLs). Therefore, it is important to refer to the kit product during the reconciliation process.
We achieve this by grouping the SVLs using the product of their associated SOL or POL. Unfortunately, we cannot rely on the product from the BoM related to the stock move of the SVL, as kits can be nested within one another. In such cases, the invoice related to the SO or the bill related to the PO would not refer to the intermediate kit we would found that way.
opw-4864925
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#221337Point of Sale now correctly follows the auto-validation setting when a cashier uses Force Done on a terminal payment. This prevents checkout from getting stuck and sends the cashier to the receipt screen as expected.
Original PR description
When doing a force done on a terminal payment, if the auto validation was turned on, it would not be triggered after clicking on the force done button. Steps to reproduce: ------------------- * Turn on the auto validation for terminal payments * Create a new order and add a product * Select a terminal payment method (You can fake the force done state as I did in the tour) * Click on the "Force Done" button > Observation: You are not redirected to the receipt screen. opw-4954406
Odoo now prevents Razorpay payment providers from being enabled and published unless the required account credentials are configured. This reduces setup mistakes that could leave a payment option visible to customers but unable to process payments.
Original PR description
## Version 17.0+ No OAuth in 16.0 ## Issue Razorpay can be enabled and published without being properly configured. ## Steps to reproduce - Go to `Payment Providers` and open `Razorpay`; - Set the state to `Enabled` and publish without providing any credentials. ## Fix Added constraints and revised account linking logic, similar to Stripe. Based on 1b6a7aeb245f0007675943ed7aacf5064e46fe61 suggested by ALSH. opw-4922315 Forward-Port-Of: odoo/odoo#219943
The Time Off dashboard now uses an employee's active running contract when calculating working schedules and holiday days. This prevents incorrect balances when an employee has overlapping contracts, such as one active part-time contract and one future or draft full-time contract.
Original PR description
Steps: -Install the hr_holidays_contract module - Create two contracts for the same employee: - Contract A (Part-time) starting from 01/01/2025 and set to Running - Contract B (Full-time) also starting from 01/01/2025 and set to New - open holiday dashboard for that employee Description of the issue/feature this PR addresses: The Time Off dashboard incorrectly considers the full-time contract instead of the part-time one, even though the part-time contract is in the running state. Cause: The contract selection logic did not correctly prioritize the running contract when multiple contracts existed for the same period. Fix: This PR updates the logic to ensure that: - If a contract is in the running state at a given time, it is used to determine the working schedule and time off calculations. - If no contract is running during that time and multiple contracts exist, the contract with the latest creation_id will be considered. task-4724155
The web interface now prevents record-opening behavior from interrupting selection dialogs. This ensures users choosing a record through “Search more” can select it as intended instead of being taken to an unrelated form view.
Original PR description
Example of steps: - install web, purchase and studio - add a many2one with studio anywhere and choose purchase.order.line - close studio - try to use this new field, select "Search more" - select a random record - It opens the form view record instead of select It This is because purchase order line has an openAction that forces the opening of a form view. However, for a select_create_dialog, we must bypass this action to allow nothing except selection. To do this, a new prop has been added, “allowOpenAction,” in the list_controller, which will be true by default, but will be false for select_create_dialog. opw-4958121
The website settings newsletter option now correctly displays the subscription checkbox for guest shoppers during checkout, even when the checkout page has been customized. This prevents missed newsletter sign-up opportunities and keeps the checkout experience consistent.
Original PR description
Reproduction Steps: --------------------------------------------------- To reproduce the issue first we need to create cowed view, follow the steps below: - Ensure that the website and…
Reproduction Steps: --------------------------------------------------- To reproduce the issue first we need to create cowed view, follow the steps below: - Ensure that the website and website_sale_mass_mailing modules are installed. - Navigate to Website > Shop. - Select any product and add it to the cart. - click on Proceed to checkout then checkout. - On the checkout page, you will see the address form. - Click on "Add a new address". - Now "Edit" the website page (e.g., make the City label bold). This will create a cowed view for the address page. Now, follow the final steps to reproduce the actual issue: - Enable the "Newsletter" option from Website Settings. - Log out of the database. - Go to the website shop, add a product to the cart, and proceed to checkout. - On the address page, the subscription checkbox is not visible for a "Guest" user. Root Cause: -------------------------------------------- The subscription checkbox does not appear because the cowed view of the newsletter is not activated. Solution: --------------------------------------- As of SaaS 17.3, a new module `website_sale_mass_mailing` was introduced, which adds the "Newsletter" option in Website Settings. When this option is enabled, the newsletter view is automatically activated. However, the corresponding cowed views are not automatically activated, causing the subscription checkbox to be missing during guest checkout. To fix this, we ensure that the corresponding cowed view is also activated when the "Newsletter" option is enabled. Related Link: https://github.com/odoo/odoo/pull/154604/files OPW-4860002 UPG-2978748 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an error that occurred when a user removed a product from the parts list on a repair order and then changed the customer. This prevents an unexpected crash during normal repair order editing and makes the workflow more reliable.
Original PR description
When User removes the product from parts in repair order and tries to change the partner, A traceback will appear. Steps to reproduce the error: - Install ``repair`` module - Create new repair order > Add a line > Add a product in parts > Save - Remove product from parts > change customer > Save Traceback: ``` AssertionError: precision_rounding must be positive, got 0.0 ``` https://github.com/odoo/odoo/blob/122dece7eeedbf670254aebd2a2d69642b381547/addons/repair/models/repair.py#L319 When user removes the product from parts, ``precision_rounding`` becomes 0.0 Which results in the above traceback. sentry-6650889934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where website links meant to be absent could become empty links when a CDN was enabled. It prevents the shop address form submit button from triggering an unintended page refresh, making checkout address submission more reliable.
Original PR description
In QWeb, when using `t-att-href='None'`, the attribute is omitted from the DOM. However, when a CDN is used, `None` is converted to an empty string (`''`) by `get_cdn_url`. This is a follow-up to commit 3e9c953. This fix addresses an issue on the `/shop/address` page where the "Submit" button had `href=''`, causing JavaScript event handling to break due to a race condition triggered by a page refresh during form submission (POST).
This update brings Odoo’s spreadsheet component up to the latest version and fixes issues affecting pivot table measures and OFFSET formula recalculations. Users should see more reliable spreadsheet results, especially in reports and analyses that depend on pivots or dynamic formulas.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ec79db448 [REL] 18.0.40 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ec79db448 [REL] 18.0.40 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/76b039095 [FIX] Pivot: sanitize measure id [Task: 4876828](https://www.odoo.com/odoo/2328/tasks/4876828) https://github.com/odoo/o-spreadsheet/commit/4e8a7908a [FIX] Functions: OFFSET dependencies are not correctly added [Task: 5001405](https://www.odoo.com/odoo/2328/tasks/5001405) https://github.com/odoo/o-spreadsheet/commit/07aff72b3 [IMP] demo: Add error handler [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/997e25a1a [REL] 18.0.39 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fix prevents invoices from failing when early payment discount settings are changed after an invoice has already been posted. It adds a safety check so missing discount dates no longer cause an error during payment reconciliation or eligibility checks.
Original PR description
Although unsure how, it seems that we can reach a way where the first payment term's discount date is False. We now add a check of its existence before comparison and a fallback on the latest discount date if it does not yet exist. opw-4982286
This fixes a display issue where the showcase block in email marketing could appear stacked in received emails on large screens, even though it looked correct in the editor. The change keeps the layout side-by-side as intended, improving consistency between email design and delivery.
Original PR description
Problem: On large screens, the `s_showcase` template shows blocks stacked vertically instead of side-by-side as in the editor. Cause: After commit 10008b32334152ada1a847b091189d1d9d5aa3d3,…
Problem: On large screens, the `s_showcase` template shows blocks stacked vertically instead of side-by-side as in the editor. Cause: After commit 10008b32334152ada1a847b091189d1d9d5aa3d3, `s_showcase` was refactored to fix selection/formatting issues. Mixing relative widths (`col-sm`) with fixed widths (`col-1`) breaks in `convert_inline`, exceeding the 12-column grid. Solution: - Use `Math.floor` when calculating the `colSize` to prevent overflow Before: <img width="1862" height="948" alt="image" src="https://github.com/user-attachments/assets/35d82103-1f84-4754-862d-50ef3481bcb3" /> After: <img width="1847" height="955" alt="image" src="https://github.com/user-attachments/assets/20e1b454-dfc4-4ad0-9e6a-3b38c230d0fd" /> Steps to reproduce: 1. Open a new email marketing. 2. Drop the `s_showcase` snippet. 3. Send a test email. 4. Observe the received template is misaligned compared to the editor. opw-4946126 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an accounting issue where invoice journal item amounts could be recalculated incorrectly if a user switched from a foreign currency to the company currency and then back before saving. This helps ensure balances and currency amounts remain accurate, reducing the risk of incorrect accounting entries.
Original PR description
Steps to reproduce: - Enable a foreign currency with rate - Create an invoice in foreign currency - Switch to company currency, then back to foreign currency before saving - Check journal items values Issue: Amount currency and balance have been affected by the currency rate even if the original currency was restored before saving opw-4864994 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
Payroll exports now check required work entry codes before generation and show clear user-facing errors instead of failing unexpectedly. This helps Belgian payroll teams identify missing setup for providers such as Group S, Acerta, Partena, Prisma, SD Worx, and UCM before sending exports.
Original PR description
Before this commit no usererror was raised when the work entry type has no group s code defined which caused the export to fail. This commit adds a check at generation time for the work entry type to have a group s code defined task-4241431
Batch payments in bank reconciliation now show the full related invoice or journal entry amount instead of only the paid amount. When an early payment discount applies, the widget also displays the discount line, making reconciliation totals clearer and more accurate for finance users.
Original PR description
In the bank reconciliation widget, it is now possible to have batch payments containing payments linked to only invoice_ids. Such batch payment, once mounted in the widget, should reflect the invoice or move amounts of its payments, and not only the payments amount. In the case of a payment-invoice combo that's elligible for an early payment discount, the early payment discount should also be displayed in the widget. Example: Invoice of 1000$ with possible EPD of 2%. A payment (with no move) is done (paid in the "early" period) for 980$. The payment is then put into a batch payment. Once in the bank rec widget, when mounting the 980$ batch payment to a statement line of 980$, the widget should display it as a batch payment line of 1000$ and add another 20$ Early payment Discount line. task-4681366
Dutch VAT payment wizards now use the Omzetbelastingnummer when it is available, instead of always relying on the company VAT number. This prevents incorrect payment communication references and helps Dutch companies submit tax payments with the right identifier.
Original PR description
**Steps to reproduce:** - Install Accounting, l10n_nl and l10n_nl_reports_sbr_ob_nummer - Switch to a Dutch company (e.g. NL Company) - In company form, set VAT and Omzetbelastingnummer - Create an…
**Steps to reproduce:** - Install Accounting, l10n_nl and l10n_nl_reports_sbr_ob_nummer - Switch to a Dutch company (e.g. NL Company) - In company form, set VAT and Omzetbelastingnummer - Create an invoice with tax for previous month - Confirm the invoice - Go to "Accounting / Reporting / Statement Reports / Tax Return" - Select previous month - Create "Closing Entry" and post it - On "Miscellaneous Operations" journal in Accounting dashboard, click on "Pay tax: [date]" link - A wizard will appear fot the VAT payment **Issue:** The value of the "Communication" field is incorrect. **Cause:** The "Communication" field is always computed from the VAT of the company. However, when the "Omzetbelastingnummer" field is set, it should be used instead of the VAT. **Solution:** Use the "Omzetbelastingnummer" field to compute the "Communication" of the VAT payment when it is set. This is done through an overridden method because "Omzetbelastingnummer" is defined in an independent module. opw-4836615
When an applicant is hired through the salary configurator, their skills are now transferred to the new employee record. This prevents HR teams from losing useful hiring information and avoids manual re-entry after onboarding.
Original PR description
Originally, an applicant, who became an employee through the salary configurator flow, loses his skill info. So, the migration of applicant information, through the salary configurator flow, to employee view has been adjusted.
Fixes an access error that could block manufacturing users from stopping work order operations linked to billable projects. This ensures production time can be recorded reliably even when the user does not have accounting permissions.
Original PR description
To reproduce:
=============
- create a BOM with an operation having an expected duration
- make sure the product of BOM has MTO and Manufacturing routes
- create a Billable project with visibility=portal
- create an SO with the product of BOM and set the project for analytic distribution
- confirm the SO -> a MO is created
- with a user having:
- hr.group_hr_user
- mrp.group_mrp_manager
- project.group_project_user
- hr_timesheet.group_hr_timesheet_approver
- go to the MO and start the first operation and wait to exceed the expected duration
- stop the operation -> access error on the analytic account line
Problem:
========
when the user tries to stop the operation, at first moment AAL will be created, as we exceed the expected duration, we will try to update the AAL which leads to an access error as the user does not have accounting rights.
Solution:
=========
deal with AAL records as sudo
opw-4897142Egyptian payroll tax calculations now apply the exempt amount before calculating income tax. This helps prevent employees from being overtaxed and improves payroll accuracy.
Original PR description
Issue: - The income tax calculation in Egyptian payroll did not properly account for the exempt amount. - This could result in over-calculating tax for employees by not applying the exemption. Fix: - Updated the 'Taxable Amount' salary rule to correctly apply the exempt amount before tax is calculated. Task-4815156
Batch payment reconciliation now skips bill or invoice installment lines that have already been reconciled. This prevents errors when paying and reconciling multiple installments from the same bill, allowing accounting teams to complete staged payments normally.
Original PR description
**Steps to reproduce:** - Install accountant - Go to "Accounting / Configuration / Invoicing / Payment Terms" - Create a payment term having at least 2 installments (e.g. 20%-80%) - Create a bill: *…
**Steps to reproduce:** - Install accountant - Go to "Accounting / Configuration / Invoicing / Payment Terms" - Create a payment term having at least 2 installments (e.g. 20%-80%) - Create a bill: * Vendor: [any] * Payment terms: [the created payment term] * Amount: 1000 - Confirm the bill - Pay the first installment from the bill (i.e. 200) - Go to "Accounting / Vendors / Payments" - Select the payment and create a batch - Validate the batch payment - From Accounting dashboard, go to Bank journal - Create a statement: * Partner: [None] * Amount: -200 - Reconcile the statement with the batch payment - From the bill, pay the second installment (i.e. 800) - Go to "Accounting / Vendors / Payments" - Select the payment and create a batch - Validate the batch payment - From Accounting dashboard, go to Bank journal - Create a statement: * Partner: [None] * Amount: -800 - Reconcile the statement with the batch payment **Issue:** The following UserError is raised: "You are trying to reconcile some entries that are already reconciled." **Cause:** When reconciling a batch payment, all the payment term lines from the invoices/bills linked to the payment are used. However, in this case, when the first batch payment has been reconciled, the first payment term line of the bill (linked to the first installment) has been reconciled. It should not be reused when reconciling the second batch payment. **Solution:** Exclude reconciled payment term lines when reconciling a batch payment. opw-4830185
DHL shipping rate requests during ecommerce checkout now use a planned date in the future. This prevents customers from seeing an avoidable DHL error when rates are calculated with the current date and time.
Original PR description
Before this commit: During checkout on Ecommerce website the default date of the order is current date and time. There is no option to change the date when getting rate. Which results in an error that the date must be in the future. After this commit: `Planned_date` for getting rate is set in furture to avoid the error. Docs reference: https://developer.dhl.com/api-reference/dhl-express-mydhl-api#reference-docs-section under rating endpoints. opw-4849754 Forward-Port-Of: odoo/enterprise#91705
Preparation display category settings now also cover products in their subcategories. This ensures kitchen or preparation teams see all relevant orders without needing every subcategory selected manually.
Original PR description
Issue: Before this commit the subcategries of the selected categories in a preparation_display config were not taken into account. Task-4841345
This fix removes an internal step that could release record locks too early when sending Mexican electronic invoices. It lowers the risk of the same invoice being sent twice to SAT, while keeping error handling and logging in place for timeout cases.
Original PR description
Following PR odoo/enterprise#89397 with commit 062f98ea1f2df7cff45fc0a9a88abcd99d0adc1e, we did an intermediary commit to make sure we store the post_time before sending. But the sending itself…
Following PR odoo/enterprise#89397 with commit 062f98ea1f2df7cff45fc0a9a88abcd99d0adc1e, we did an intermediary commit to make sure we store the post_time before sending. But the sending itself catches the exception for timeout, ... so the only case where it would fail is if our own servers crash (through an all destructive fire e.g., which is a very small risk). Otherwise they would save the error without returning it. The bigger danger however is that when you do a commit, you lose the locking on the records that were done, so you effectively risk sending the same record twice at the same time because the locking is not active anymore during the sending. Even if the Odoo invoice name is the same, it is interpreted by the SAT as 2 different invoices. Of course, if we have a timeout and it is sent again, we will have a duplicate, but the user should be alerted about it as exceptions are caught and put in the error message. We added however logging for all those cases to be able to follow it up. opw-4980638, ...