Daily updates from Odoo
Tuesday, July 28, 2026
41 changes · master
Enhancements to existing features
UrbanPiper food delivery settings are now managed in a dedicated store setup instead of being spread across each point-of-sale configuration. This makes store management cleaner and adds more flexible options for pricing, taxes, notifications, timings, and customer creation.
Original PR description
*: pos_restaurant_urban_piper, pos_enterprise, l10n_in_pos_urban_piper Introduces a dedicated `pos.urbanpiper.store` model to manage UrbanPiper store configurations for food delivery. Configuration…
*: pos_restaurant_urban_piper, pos_enterprise, l10n_in_pos_urban_piper Introduces a dedicated `pos.urbanpiper.store` model to manage UrbanPiper store configurations for food delivery. Configuration fields previously scattered across `pos.config` are migrated to this new model, giving each POS configuration its own linked UrbanPiper store record. This results in cleaner separation of concerns, easier extensibility, and a more streamlined UI for store management. **New model: `pos.urbanpiper.store`** - Replaces UrbanPiper-related fields previously stored directly on `pos.config` - Each POS config is linked to exactly one UrbanPiper store - Supports additional configuration fields without polluting `pos.config` **New features** - Provider-based pricelist support - Tax type configuration (inclusive or exclusive) - Customizable order notification sound - Preset support for managing: - Fiscal position - Store global pricelist - Store operating timings - Customer creation control ## Related - Task: `4977992` - Community: https://github.com/odoo/odoo/pull/260408 - Upgrade: https://github.com/odoo/upgrade/pull/9757
Accounting teams can now configure depreciation models and related asset accounts more flexibly, with key fields always visible and fewer restrictions during setup. Asset imports are also easier because depreciation model data and related accounts can be included directly in import templates.
Original PR description
This commit applies several improvements to the account and depreciation model. These changes are: - The `accumulated depreciation` and `depreciation expense` fields on the account form view are…
This commit applies several improvements to the account and depreciation model. These changes are: - The `accumulated depreciation` and `depreciation expense` fields on the account form view are changed to be always visible even if no depreciation model is selected. - Remove condition to limit asset creations for accounts being used as accumulated depreciation on other fixed asset accounts. It caused problems for many users trying to configure the accounts. Each country could have different configuation needs. - The depreciation model's name can now be edited while still keeping the auto-naming - The depreciation model auto-naming is slightly changed to be shorter when it's has a linear or degressive method. - The depreciation model export now includes more fields by using new export template - The asset import template has a new sheet for depreciation model data to be used to import depreciation models. Also depreciation and expense accounts can be imported directly to the asset, they are added as non-required fields to the asset template. The whole purpose is to ease asset imports as much as possible without having to pre-configure fixed asset accounts. - New button was added in the accounting import screen for importing depreciation models. task-6283929
The appointment selection page now uses a clearer card-style layout consistent with the website appointment flow. Portal users also get a clearer preview notice, helping them understand when they are viewing appointment options before choosing one.
Original PR description
Purpose ======= Improve the look of the appointment selection page in the appointment module to match the look of the appointment selection in website appointment. Specification ============= Changing the appointment dropdown to match the website 'appointments list' layout. Moving templates from website appointment to appointment, cleaning scss rule, and remove now useless javascript interactions and test helpers. Adding a portal alert to inform that it's a preview of the appointment list selection, like it already existed after selecting an appointment type, except instead of redirecting to the selected appointment form, it redirects to the appointment list view. Inheriting the appointment template in website appointment to add the 'published' ribbon and sample images. Task-6185274
The employee time-off planning view now loads data in batches and only retrieves the relevant date range. This makes large team views much faster, reducing wait times from several seconds to about one second in key scenarios.
Original PR description
At odoo, our friendly kitchen chef needs to know who is off on any given day. To know that, they use the holiday gantt view and display all employees and check the sum. For 200+ employees working at GR2, `get_gantt_data` takes 7+ seconds `_unavailable_intervals_batch` is called for each individual version, which means it's not batched. Ultimatly, it leads to lots of sql queries that could be grouped together. With this commit, the calls are batched per calendar before: ~7s after: ~900ms-1s Forward-Port-Of: odoo/enterprise#125490 Forward-Port-Of: odoo/enterprise#124820
The time off Gantt view now offers a cleaner popup when creating multiple requests at once. It also handles multi-day and half-day selections more reliably, reducing validation errors caused by overlapping requests.
Original PR description
task-5941912
The Peru electronic invoicing module updates debit note reason options to match new SUNAT requirements effective August 1, 2026. Businesses creating Peruvian debit notes will have the new “Penalties” reason available and the existing “Other concepts” label updated for compliance.
Original PR description
Purpose: SUNAT has issued new validation rules and database updates for EDI. The changes are mandatory and is effective starting August 1, 2026. To stay compliant, the debit note reasons need to be updated when creating a debit note in Peru. A new code 13 with label "Penalties" is added to the list of reasons. Code 03 reason need its label to be updated to "Other concepts." Task [link](https://www.odoo.com/odoo/project.task/6312025) task-6312025 Forward-Port-Of: odoo/enterprise#122320
Belgian payroll now flags paid public holidays that fall within the first two weeks of economic unemployment and assigns them to the correct leave type. Payroll officers receive a warning when this split occurs, helping them review payslips and reduce payroll classification errors.
Original PR description
This change aims to grab the attention of payroll officers to the paid public holidays during the first two weeks of economic unemployment "LEAVE6665" and change the leave type to "LEAVE207" instead of "LEAVE500" Moreover, the split will be highlighted through a warning popup. Task: 6275590
Egyptian payroll rules now calculate pay more consistently using actual working days instead of a mix of fixed 30-day assumptions and working-day logic. Required employee payroll details are restored as standard employee fields, helping ensure accurate calculations and compliance exports across employees.
Original PR description
Purpose: - Some salary rules result in wrong computation as they are already handled in working days - Revert property inputs to fields as they are not optional and they need to be on all employees - Some of the calculations are based on working days and some are based on 30, we want to change that and make everything based on working days and have the user adapt the working schedule according to their needs. task-id: 6289200
Belgian payroll DMFA checks now show all validation issues and anomalies in a dedicated tab instead of stopping at the first problem. This helps payroll users review and resolve blocking and non-blocking issues more efficiently before creating declarations.
Original PR description
Currently, validation errors and anomalies on dmfa are raised one by one, making it a UX nightmare to fix the errors (you only see one at a time). Here, we refactor the code so that we have a new issues field on dmfa which computes the errors that are now defined as records of hr.payroll.warning we display this in a new tab in the form view of the dmfa. Task: 6267586
Marketing automation now processes campaign participants, activity traces, and WhatsApp-related messages in batches, improving performance for larger campaigns. The change also clarifies participant statuses and centralizes related update logic, making the feature easier to maintain and scale.
Original PR description
Improve traces and participants synchronization performance by batching operations. Introduce slicer usage so that batching is done under manageable chunk sizes. Improve whatsapp performance by batching part of the message creation process. Centralize code managing traces and participants status update, easing code understanding, maintenance and update. See sub commits for more details. Task-4224152: [marketing_automation] Performance / Scalability
Belgian payroll now offers two clear flexi contract employee types: Flexi-Employee with worker code 450 and Flexi-Worker with worker code 050. This replaces the previous generic Flexi-Job type, helping HR teams select the correct classification more easily and reduce setup errors.
Original PR description
Currently, there is two possibilities for people in flexi contracts, either they use worker code 450 or 050. In the current employee type, default flexi-job doesn't has default worker code. In this PR, expected to introduce new employee types - Flexi-Employee with worker code 450 - Flexi-Worker with worker code 050 It also removes the existing Flexi-Job employee type. This implementation simplifies HR operations by providing dedicated employee types with predefined worker codes. task: 6364410
Payroll payment export options can now be tailored by country and extended more easily. This reduces irrelevant choices in multi-country payroll setups and helps select the right default export format automatically.
Original PR description
Update the export_format field to use a callable for both the selection list and the default value. It has a few goals: - Allow to add new options without needing to update the module, for cases where it could make sense. - Allows to make the options country specific, reducing the amount of irrelevant options shown in multy countries databases. - Allow a better handling of default values, allowing to make them country specific. task-6363995
Belgian payroll now applies a quarterly cap to employer social security contributions, preventing employer contributions from exceeding the allowed limit across payslips in the same quarter. The change adds the required payroll rule, reporting support, and tests so Belgian payroll calculations and DMFA reports reflect the capped deduction correctly.
Original PR description
[IMP] l10n_be: employer contribution capping
. Quarterly employer contribution capping should be applied for Belgium.
. New salary rule parameter for capping amount
. New salary rule ONSSEMPLOYERBASICDEDUC to calculate the deduction of ONSSEMPLOYERBASIC in each payslip.
. In short, we are looking (cap_amount - total ONSSEMPLOYERBASIC this quarter)*basic_rate - previous deductions in this quarter
. By this way, you can't overflow the capped employer contribution.
task - 6279204India payroll employer cost calculations now use gross salary instead of net salary by default. This gives businesses a more accurate view of employee cost because gross salary better reflects the cost baseline before net pay deductions.
Original PR description
In this PR, for the India localization, we were using NET as the default value for employer cost computation. Instead of NET, we will now use GROSS, as it provides a more accurate representation of employer cost: Employer Cost >= GROSS >= NET. Technical - set appear_in_employee_cost_dashboard=False in India:Intern and India:Employee pay in NET salary rule. - set apprear_in_employee_cost_dashboard=True in India:Intern and India:Employee pay in Gross salary rule. task: 6323947
Saudi payroll now helps HR track employees whose wage, housing allowance, or other allowances have changed. HR managers receive a notification, and the required GOSI wage update report is available from the reporting menu for upload to the GOSI platform.
Original PR description
GOSI wage update report is needed to be uploaded to GOSI platform for each employee that changes their wage, housing allowance, or other allowances. Consequently on the change on any of these fields, a notification will be created for the HR manager and the report to be uploaded will be accessible through the reporting menu with the employees that were updated. Task: 6380424
Belgian payroll now includes the required pension and subsistence fund contribution rules for both workers and employees. This helps employers calculate and report the correct DMFA contribution codes in line with social security requirements.
Original PR description
add for Workers → 826 & 827 For employees → 836 & 837 rules depending on Source: https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/instructions/special_contributions/other_specialcontributions/subsistenceprotectionfunds.html and add it in the dmfa Task Id: 6259626
Belgian payroll now records the fiscal month and quarter used for 274.xx withholding tax declarations and carries that information into related accounting journal items. This makes it easier to reconcile payroll taxes when declarations are settled in a different period than the work performed.
Original PR description
**Why:** In Belgian payroll accounting, taxes can legally be declared and settled in a month or quarter other than the one in which the actual work was performed. Currently, this mismatch makes it difficult to reconcile financial journal entries with the official 274.xx withholding tax forms. **What:** - Added fiscal_month and fiscal_quarter fields to track the 274.xx tax declaration periods. - Extended the payroll journal entry mapping to pass this fiscal period information directly down to the generated account journal items. task-6233232
This update makes BioTime attendance integration easier and safer to use by hiding related menus until setup is complete and improving how punch records are processed. It also improves time conversion, attendance deletion handling, and adds tests to reduce errors in daily attendance workflows.
Original PR description
- Hide the Transactions/Terminals menus and block their views until BioTime is configured; Test Connection reloads so the menus surface. - Convert BioTime punch times to UTC using the employee timezone. - Reset and flag linked transactions when their attendance is deleted, and keep the guard against deleting processed-and-linked ones. - Replace the cog server action with Fetch/Process/Re-Fetch list-header buttons; allow editing punch_type when the fetched value is unsupported. - Compute processing_note from the transaction state instead of writing it ad hoc across methods. - Add shared _notification and _mark_processed helpers and drop dead code (unused params, unreachable guards, redundant cache clearing). - Add tests covering the processing, sync, and access-gating paths. Task-6181807
Belgian payroll declarations can now include an employee's risk class when one is defined. This helps produce more complete DMFA filings and reduces the need for manual adjustments or missing declaration data.
Original PR description
The `ActivityWithRisk` tag is currently disabled by hardcode. This commit populates the tag with the value of the employee's risk class, if any. TaskID: 6409073
Payroll now supports optional categories on time off types, letting businesses add extra classifications when creating time off and use them in payroll calculations. Belgian premium pay rules are being moved to this more flexible approach, alongside a correction to non-recurring benefit contribution calculations.
Original PR description
Allowing to define optional categories on time types, which can be optionally added on time off creation. Migrating the Belgian premium pay to utilise this system. task-6297699
Document-related counters now update automatically when attachments are added or removed, so users see accurate information without manually reloading. This improves reliability for records that use document management and adds test coverage to protect the behavior.
Original PR description
This commit enables the chatter to automatically trigger a reload of the stat buttons whenever an attachment is added or removed from a model inheriting `documents.documents_mixin`. To achieve this at the frontend level, a new computed attribute was added to the `mail.thread` store to serve as a marker, allowing the chatter to detect the mixin's presence and adjust its reload behavior accordingly. Tests in `test_documents_full` have been updated to ensure the bridge logic correctly handles document creation and deletion. Related-PR: https://github.com/odoo/odoo/pull/265280 Task-6148224
Resolved issues and error corrections
AI-assisted record creation and updates now handle database validation failures as normal retryable errors instead of causing unrecoverable crashes. The change also improves access to required model information so the AI agent can complete more business flows reliably.
Original PR description
Prior to this commit, the create and update tool calls could cause an unrecoverable error if the model tried to use values which were causing an SQL constraint to fail. With this commit, we add a try..except block with a savepoint to treat the SQL constraint errors as regular errors, ensuring that the model is able to retry if it misses a check. task-6196137 Forward-Port-Of: odoo/enterprise#125226 Forward-Port-Of: odoo/enterprise#121607
Belgian EC Sales List PDF and XML exports now use the correct foreign VAT number when a company reports for Belgium from another country. This helps prevent incorrect tax declarations and keeps the exported compliance documents aligned with the fiscal position settings.
Original PR description
### Issue before this commit: When a company generates an EC Sales List for a foreign country (e.g., a Luxembourgish company running a Belgian report), the exported XML and PDF files incorrectly…
### Issue before this commit: When a company generates an EC Sales List for a foreign country (e.g., a Luxembourgish company running a Belgian report), the exported XML and PDF files incorrectly display the company's primary domestic VAT number instead of the foreign VAT number defined in the fiscal position in the tag DeclarantReference. ### Steps to reproduce the issue: 1. Download Accounting and l10n_lu 2. Switch to LU company 3. Go to Fiscal Positions in settings and create the Belgian position (insert country as Belgium and Foreign Tax ID as BE0477472701) 4. A pop up will appear saying: Click to create the taxes for this country. so click there to create the taxes 5. Go to Invoices and create a new invoice and be sure that: 1. be sure the customer has a VAT number in their profile 2. in tab Other Info the Fiscal Position is set to Belgium 3. the tax applied is 0% EU S (BE) 4. date of invoice is in June 6. Open the tax return in 1 July 7. Open EC Sales List June 2026 (BE) and mark as reviewed all the lines 8. Click on Validate 9. Open the XML and PDF file created and see that the tag DeclarantReference is wrong because it reports the data of LU company instead of BE company ### Cause of the issue: The `export_to_xml_sales_report` method relied on legacy code (company.partner_id.vat) to fetch the VAT number. It failed to use the centralized `get_vat_for_export(options)` method, thereby completely bypassing the foreign VAT logic correctly implemented in other tax reports. ### Reason to introduce the fix: To ensure tax compliance by appling the correct VAT number from the foreign fiscal position. opw-6170447 Forward-Port-Of: odoo/enterprise#125210 Forward-Port-Of: odoo/enterprise#124698
Envia shipping rate requests now send insurance details in the format expected by the carrier API. This ensures customers receive accurate delivery quotes when insurance is enabled on an Envia delivery method.
Original PR description
Issue ----- Insurance request is not reflected on the rating given by Envia. Steps to reproduce ----- - Create a MX company - Set up Envia - Fedex Nacional Economico (ground) - Create a MX client - Create a product (with some weight) - Create a SO - Add the product - Add envia delivery and get a rate - Update Envia delivery method - Set insurance to 50% - Go back to the SO - Add envia delivery and get a rate > The rate is the same both times Cause ----- We are passing the insurance value as a `insurance` field on the shipment, which is not what the API expects. We should instead pass it in `additionalServices` as shown in the example of https://docs.envia.com/docs/additional-services#how-to-add-services-to-a-shipment Follow up of 7258e4a ----- Ticket: opw-5254952 Forward-Port-Of: odoo/enterprise#124923 Forward-Port-Of: odoo/enterprise#124700
Belgian payroll now updates an employee's work location details when DMFA work address settings are added or changed. This ensures payroll fields such as regional tax and reduction options appear correctly for eligible employees.
Original PR description
[FIX] l10n_be_hr_payroll: fix stale location unit
Bug reproduction:
1 - L10n_be -> belgium company
2 - create employee and assign work address My Belgium Company
3 - Payroll settings -> Work address DMFA codes -> add My Belgium Company to there -> Competence: Wallonia
4 - Go back to employee -> payroll tab -> In taxes & reduction section you need to see Impulsion Plan field.
Bug cause:
1 - Right now, version's location_unit changes only address_id is changed
2 - When new location_unit is added or when location_unit is edited, it does not reflect to version's location.
Bug solution:
1 - In L10n_BeDmfaLocationUnit model, in create and write functions I'm adjusting the location_units of the affected versions.
2 - Since location_unit is fixed, l10n_be_working_region is fixed as well.
task - 6355995
Forward-Port-Of: odoo/enterprise#122623French VAT declarations now handle SIRET numbers even when users enter spaces, reducing failed submissions. The update also checks bank account number formatting and warns users when the information may be incorrect before sending.
Original PR description
This commit resolves an issue where VAT declarations failed when the provided SIRET number included spaces. Since check_siret verifies the format, we now strip all spaces from the input. Additionally, this commit introduces a validation for bank account numbers, ensuring that we warn the user if the account number is wrongly formatted. task-6253745 Forward-Port-Of: odoo/enterprise#125467 Forward-Port-Of: odoo/enterprise#120689
Users with manufacturing rights and sales access limited to their own documents can now edit manufacturing orders created from rental-related sales flows without hitting an access error. This prevents unnecessary work stoppages while preserving the existing sales order visibility restrictions.
Original PR description
### Steps to reproduce: - Ensure `sale_stock_renting` is installed - Enable Multi-Steps Routes > Unarchive MTO - Create a product P with a BoM and the routes MTO + manufacture - Create anc confirm a…
### Steps to reproduce: - Ensure `sale_stock_renting` is installed - Enable Multi-Steps Routes > Unarchive MTO - Create a product P with a BoM and the routes MTO + manufacture - Create anc confirm a sale order for A unit of P - Log in with an other user with with mrp User rights and sales User: Own Documents Only (he should not have access to the SO) - Open the MO, add a component line and save #### > Access Error: Blame the following rule: - Personal Order ### Cause of the issue: Writing on the `move_raw_ids` will trigger a call of the `_autoconfirm_production` in order to confirm the newly created move: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L990-L991 https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L1422-L1423 During this confirmation process, one calls the `_merge_moves` method in order to merge this new move (if relevant) to any already existing one. https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/stock/models/stock_move.py#L1575-L1576 Now, the issue is that, `sale_stock_renting` module overrides the method `_prepare_merge_moves_distinct_fields` determining the fields relevant to the merge by requiring a read access to the `is_rental_order` compute field of the `sale_order` linked to the MO: https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/sale_stock_renting/models/stock_move.py#L34-L40 However, due to the 'Personal Orders' ir.rule, the user does not have a read access to this record: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/sale/security/ir_rules.xml#L44-L49 Community: https://github.com/odoo/odoo/pull/271017 opw-6275658 Forward-Port-Of: odoo/enterprise#121845 Forward-Port-Of: odoo/enterprise#121135
Fixed an issue where Avalara-related fields could be hidden on Canadian contacts when working with a US company. This ensures users can see and manage the correct Avalara tax information for cross-border contacts.
Original PR description
**Steps to reproduce:**
- Install Accounting and account_avatax
- Use a US company (by default)
- Create a contact with Canada as country
**Issue:**
In "Sales & Purchase" tab, all the fields from avatax module are not displayed (i.e. "Avalara Code", "Avalara Partner Code", "Avalara Exemption").
**Cause:**
The `invisible` property of those fields is using `fiscal_country_codes` char field.
If no company is set on the record, `fiscal_country_codes` will contain the country code of the selected companies in addition to the country code of the record.
In this case, the value of `fiscal_country_codes` will be `US,CA` string, which triggers `fiscal_country_codes not in ('US', 'CA')` invisible condition.
opw-6328395
Forward-Port-Of: odoo/enterprise#125543
Forward-Port-Of: odoo/enterprise#124619This fix prevents errors when trashed Knowledge articles are cleaned up if they are linked to Annual Reports. The cleanup now also removes the related annual report records, avoiding failed background jobs and keeping accounting review data consistent.
Original PR description
When a knowledge article linked to an Annual report is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install…
When a knowledge article linked to an Annual report is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install ``accountant_knowledge`` module - Go to Accounting > Review > Annual Report > Create a new annual report - Go to Knowledge > Open the knowledge article linked to the annual report > Send to Trash - Run the ``Base: Auto-vacuum internal data`` cron Traceback: ```py ForeignKeyViolation: update or delete on table "knowledge_article" violates foreign key constraint "audit_report_knowledge_article_id_fkey" on table "audit_report" DETAIL: Key (id)=(67) is still referenced from table "audit_report". ``` https://github.com/odoo/enterprise/blob/04cce2e400ce2e412f28aa1849078a7c40ff0e2c/knowledge/models/knowledge_article.py#L1069-L1070 The garbage collector deletes trashed knowledge articles that match its domain. Since this domain also includes articles linked to Annual Reports, the cron attempts to delete records that are still referenced by annual report, resulting in a foreign key violation error. Solution: Ensure linked audit reports are also deleted during knowledge article garbage collection. sentry-7488793071 Forward-Port-Of: odoo/enterprise#125525 Forward-Port-Of: odoo/enterprise#121189
This fix restores the validation flow for Indian GSTR tax returns after a related screen layout change caused the return view to break. Businesses using Indian tax reporting can continue validating GSTR returns with the expected workflow and button behavior.
Original PR description
Fixed the broken view for indian tax returns due to parent view refactor. Update the Indian GSTR return workflow to: - adapt the kanban button inheritance to the new view structure, - preserve the custom GSTR Validate button independently of unresolved checks, - Keep the GSTR-specific validation workflow unchanged. - remove indian loc specific validate button instead use from parent. - some code cleaning. task-6365198 Forward-Port-Of: odoo/enterprise#123207
This fix ensures Brazilian Avalara tax requests keep important customer tax settings even when their values are blank or false. It prevents Avalara from choosing the wrong CFOP code, helping invoices receive the correct fiscal classification.
Original PR description
## Steps to reproduce: 1. Install `l10n_br`, `l10n_br_avatax`, and `l10n_br_edi_fiscal_reform`. 2. Ensure that Demo mode is activated if not on Runbot. 3. Navigate to Contacts, then click into "BR…
## Steps to reproduce:
1. Install `l10n_br`, `l10n_br_avatax`, and `l10n_br_edi_fiscal_reform`.
2. Ensure that Demo mode is activated if not on Runbot.
3. Navigate to Contacts, then click into "BR Company Customer Estimated Profit".
4. Duplicate this contact, then set the following fields:
1. Tax Regime set to individual
2. ICMS Taxpayer Type set to Non-Taxpayer
5. Swtich to the BR Company and go to Accounting / Configuration / Settings.
6. Set up a Sandbox Avalara account and enable logging payload responses.
7. Navigate to Accounting > Customers > Invoices.
8. Create an invoice with:
1. Customer set to the copy created earlier.
2. Operation Type set to Sale of Goods
3. Document Type set to 55
4. Payment Method Brazil set to Money
5. Presence set to Present
6. One sales order line with:
1. Regular Consumable Product
2. quantity set to 1
3. price set to 100.0
9. Confirm the invoice.
10. Navigate back to Accounting > Configuration > Settings to view the response from Avalara. The customer will have the CFOP 6102 instead of CFOP 6108.
Explanation:
PR #97845 introduced `_l10n_br_deep_clean_dict()` to remove falsy values and empty dictionaries from the payload we send to Avalara. This fix was applied as broadly as possible to prevent excessive if statements.
However, if the falsy values in taxSettings of the customer are not communicated, Avalara will assign the customer to an incorrect CFOP.
opw-6085964
Forward-Port-Of: odoo/enterprise#124730
Forward-Port-Of: odoo/enterprise#120783The Belgian payroll report now calculates IPA reductions using the proper salary components instead of the full taxable amount. A dedicated IPA tab makes these lines easier to review, helping payroll teams produce more accurate 274xx declarations.
Original PR description
-add tab for IPA in 274xx sheet and add new field `line_ipa_ids` to display them in the new tab -fix the old calculations for the IPA where previously was equal to total_taxable_amount but now based on all salary components subject to ONSS salary components that are taxable but no ONSS travel expenses (except bike expenses) Task Id: 6333064
This fixes where Mexican CFDI invoice fields are placed so they remain visible even when other localization modules are installed. It prevents the CFDI Origen field from disappearing on Mexican invoices due to layout changes from another country-specific module.
Original PR description
The CFDI fields used //sheet/group//group[last()], which targets the last group by position. Once l10n_co_edi adds its group after header_right_group, the fields land in it instead, and it is invisible unless country_code is CO, so CFDI Origen disappears on MX invoices. Use //group[@id='header_right_group'], like l10n_co_edi already does, so placement no longer depends on what modules are installed. Task Adhoc side: 67269 Forward-Port-Of: odoo/enterprise#124545
Ecuador branch users can now create customer invoices without being blocked by an access error. The fix allows the system to identify the journal country correctly in parent-child company setups, keeping normal accounting workflows available to authorized branch staff.
Original PR description
Steps to reproduce: - Install `l10n_ec` module - Create one branch of the EC company - Give user(not admin) access to company branch and login with user - Go to Accounting > Customers > Invoices - Click New > AccessError Cause: This error occurs because the user is working within a branch of the main company. The code tries to access the journal’s company, which is set to the parent company. As the user does not have access to the parent company, fetching the country code fails. Solution: In some cases, strict company access rules cause `AccessError` and block normal flows, especially with parent–child company setups where a child needs data from the parent. To ensure smooth processing, we use a related field on the journal to retrieve the country code without directly accessing the company. opw-6087460 Forward-Port-Of: odoo/enterprise#113901
Belgian payroll calculations for CCT90 non-recurring benefits have been updated so the ONSS contribution is always applied when due, regardless of thresholds. This improves payslip accuracy and helps businesses remain compliant with Belgian payroll rules.
Original PR description
- splitted social contribution into 2 rules - made ONSS Non_recurring Benefit Contribution always due regardless of any threshold task-id: 6358022
Belgian payroll now applies the correct withholding tax exemption cap for bachelor-level research staff based on company size. This ensures payroll deductions and employee-level exemption amounts are accurate and transparent when legal caps apply.
Original PR description
Before, the bachelor exemption was hardcoded at 25% for every company, the doctor/master total never flowed into the deduction, and each employee's exempted amount in the Bachelors tab showed the raw uncapped number even when the cap applied. Now the cap is 25% for big companies and 50% for small ones, set through a salary rule parameter and defaulting to 25% when company size is not set. Each employee's amount is scaled down proportionally when the cap kicks in, so the Bachelors tab always shows what they actually get, and the total deduction reflects it correctly. task-6241566
This fix ensures existing tax returns are updated when their return workflow changes, preventing invalid old statuses from causing errors. It helps businesses avoid crashes during upgrades or configuration changes, especially when a final status such as paid is removed from the workflow.
Original PR description
To reproduce the issue: 1) Create a company in Belgium 2) Instantiate its returns and review, submit and pay one of the VAT returns 3) Change the states_worklfow of the VAT return so that it only…
To reproduce the issue: 1) Create a company in Belgium 2) Instantiate its returns and review, submit and pay one of the VAT returns 3) Change the states_worklfow of the VAT return so that it only accepts "review" and "submit" stages, not "paid" anymore 4) Go to the list of returns, remove the TODO filter => traceback The problem is here that the existing returns don't recompute their state when the workflow of the type is modified. In some cases, this is fine, but it others, it's annoying. In our example, the terminal state changed, so all the returns in that terminal stage should change their state to the new terminal one. "paid" is not an accepted value anymore, it should become "submitted". Moreover, when the workflow is changed, the selection field actually containing the state must also change. As it is, it seems to work because "state" of account.return is stored, but the value it's based on (the workflow field) won't be consistent with it. It's not annoying now, but those inconsistencies could become a big source of trouble in the future (we know that from experience ... I'm looking at you, version 8 ! è-é). This issue typically happens at upgrade. We had cases in FR and AE already. We solve that by a generic override of the write to sort things out when such change needs to happen. An upgrade PR will also be done to adapt the script so that we eventually solve the inconsistencies on dbs that have already migrated to 19.0. Forward-Port-Of: odoo/enterprise#124934 Forward-Port-Of: odoo/enterprise#124144
This fix ensures cumulative translation adjustment lines in accounting reports respect filters, horizontal groupings, and the correct reporting dates. Businesses get more reliable trial balance and ledger outputs, especially when comparing multiple companies or fiscal years.
Original PR description
The engine for the cumulative translation adjustment line was fully overriding the forced options, but this key might already be present in the options, for example, when using horizontal groups. task-6418960 Forward-Port-Of: odoo/enterprise#125725 Forward-Port-Of: odoo/enterprise#124108
Belgian payroll withholding tax reductions now apply correctly for disabled employees, disabled spouses, and spouses with low or no income even when there are no dependent children or seniors. This helps ensure affected employees receive the correct payroll tax treatment and updates related spouse income threshold wording.
Original PR description
Prior to this commit, the reductions for disabled employees, disabled spouse, and spouse with low or no income did not apply if the employee did not have any depenedent juniors or seniors. This commit fixes that, by removing the unneeded condition, and applying the reductions for those employees. This commit also updates the text for the thresholds of the spouse's fiscal situation. task-6384236 task-6320606 Forward-Port-Of: odoo/enterprise#124803
Electronic invoices sent from Colombian branches now use the parent company name in the required DIAN XML field. This helps DIAN correctly match invoices to the company tax ID and reduces rejection risk for branch-issued invoices.
Original PR description
The correct behavior should be to use the original company name in this specific XML tag For the DIAN, branch names will not be recognized as related to the NIT. So, when sending electronic invoices from a branch, the XML should use the name of the parent company of that branch. Ticket [link](https://www.odoo.com/odoo/project.task/6074280) opw-6074280 Forward-Port-Of: odoo/enterprise#125529 Forward-Port-Of: odoo/enterprise#115494
Features or functions removed from Odoo
Point of Sale receipts will no longer include extra payment terminal receipts for Worldline, Six, and Tyro terminals. This keeps customer receipts shorter and avoids duplicate or unnecessary payment details while preserving payment processing.
Original PR description
This PR removes the terminal receipts which were until now added to Point Of Sale receipts. This is removed for 1) Worldline 2) Six 3) Tyro see https://github.com/odoo/odoo/pull/278393 task-6416813