Daily updates from Odoo
Thursday, February 12, 2026
27 changes · 18.0
Enhancements to existing features
This update introduces a new method for calculating taxes on prices, using simultaneous equations. This aims to provide more accurate tax calculations, particularly in complex pricing scenarios. Currently, it focuses on fixed and percent taxes and has future potential for manual tax input.
Original PR description
For fixed and percent taxes, their amounts can be obtained from the unit price using simultaneous equations. In some complicated cases with lots of price-included taxes, this may be a simpler solver than the iterative approach which tries to batch taxes and then iteratively compute them. At the moment, this doesn't handle Python taxes (and will likely not be extensible to them). In addition, we don't handle manual tax / base amounts yet, but that should be fairly simple to implement - instead of solving for the unit price, we should solve for whatever manual tax and base amounts are supplied. task-none
This update ensures Odoo's Spanish tax reporting (l10n_es_report) complies with the latest regulations from BOE (the Spanish Official Gazette). Specifically, it incorporates changes related to Modelo 347, adding a placeholder for subsidy numbers with default zeros to meet reporting requirements. This update is crucial for accurate tax reporting in Spain.
Original PR description
reference: https://www.boe.es/buscar/doc.php?id=BOE-A-2025-25390 considering the modelo 347 As we do not have anything for the subsidy number, we just put 6 0s. opw-5926624 Forward-Port-Of: odoo/enterprise#107125
Resolved issues and error corrections
This update fixes an issue where the static file box in the HTML editor was unintentionally editable, causing confusing keyboard navigation. The change now prevents automatic editing, ensuring a smoother and more predictable user experience when working with files within the editor. This improves overall usability.
Original PR description
### Purpose of this PR: - In the static file box, the file name is contenteditable by default, which leads to unexpected caret movement and arrow-key navigation behavior. - Change the behavior so that the file name is contenteditable="false" by default and becomes editable only when the user explicitly clicks on it. The editability is reverted when clicking outside of the file name. - This ensures consistent keyboard navigation while keeping the change limited to the static file box. task-5427329 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that pickings are automatically created when validating POS orders linked to sale orders, especially when inventory management creates pickings at the end of a session. Previously, stock levels weren't updated correctly. This change improves the accuracy of stock tracking for POS sales.
Original PR description
Before this commit, when validating a POS order linked to a sale order, if the Inventory Management was configured to create pickings at the end of the session, no picking was created for the order, and the sale order stock was not updated. This commit fixes this issue by ensuring that the picking is created for the imported sale orders in real time. opw-5423113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update restricts access to cost and margin information within the Point of Sale (PoS) system. Previously, this sensitive data was visible to all users, regardless of their permissions. Now, the 'Show margins & costs' setting controls visibility, ensuring only employees with 'advanced' cashier rights can see this information.
Original PR description
Before this commit, the "Show margins & costs" setting did not correctly enforce visibility. When enabled, cost and margin information was displayed to all users, regardless of their cashier rights. Furthermore, even when this setting was disabled, this sensitive information was still visible to cashiers with advanced and minimal rights. This commit modifies the behavior: - If "Show margins & costs" is enabled, cost and margin details are visible in the PoS UI only for employees with 'advanced' cashier rights, and hidden from those with 'basic' rights. - If "Show margins & costs" is not checked, this information is hidden from all users in the PoS UI. opw-4899231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures website controller pages are correctly linked to relevant business models, resolving previous errors caused by incorrectly binding them to transient or abstract models. This improves data accuracy and stability within the website functionality.
Original PR description
Before this commit, a website_controller_page could be bound to any sort of model. For some of them this was irrelevant or plain wrong: - transient models: they are not pointing to anything relevant business wise - abstract: they cannot even have records, and most of them are mixin - _auto = False: Those are models with a table which is a custom one. The heuristics here is to say that records are not "real" ones. Also, most of these tables are sqlViews or something similar Business wise there were errors because of this, so this commit introduces a constraint that forbids the above use cases. sentry-6842596566 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where Outlook Calendar was displaying raw HTML tags in event descriptions when exporting events. The change adds a new method to correctly format event descriptions for Outlook, ensuring that event details are rendered properly in the calendar application. This improves the user experience when sharing events with Outlook.
Original PR description
****Behavior:**** **Current:** When exporting an event for Outlook Calendar, the file returned is the same as for ICalendar(.ics), however Outlook cannot handle the HTML description of the event when passed through the 'DESCRIPTION:' field which causes the event description to display raw HTML tags. **Solution:** Outlook can use the 'X-ALT-DESC:' field with 'text/html' parameter to handle HTML. A new route was created to generate the event's ics file with the correct parameters for Outlook. ****Steps to reproduce:**** - Go to an event from Website - Select the Outlook icon under 'Add to calendar' - Import the file to Outlook Calendar - You'll notice HTML tags in the description of the event. opw-5116354
This update resolves a bug where translated text couldn't be updated or removed when using highlights on editable pages. The fix ensures that all elements within a translated section are correctly processed, allowing for proper translation editing functionality. This improves the user experience when working with highlighted text in the translation editor.
Original PR description
[FIX] base, tools: fix the behaviour of inline translated elements Steps to reproduce: - Go to a website page (in "Edit" mode) > Add a "Title" snippet. - Select the whole "title" > Set a highlight…
[FIX] base, tools: fix the behaviour of inline translated elements
Steps to reproduce:
- Go to a website page (in "Edit" mode) > Add a "Title" snippet.
- Select the whole "title" > Set a highlight effect on it.
- With the same text selected, transform it to a link and save.
- Try to translate the title into another language in the editor > You
cannot update the text or remove it.
The code from [1] introduced a feature that allows forcing some specific
elements to be "translated inline" using the `o_translate_inline` class.
It was used mainly to handle specific cases where elements DOM is
handled in JS in a way that breaks the "Translate" editor (e.g., text
highlights).
By forcing the highlight `<span/>`s to be inline translated, the fix
from [1] only handled situations where a highlight effect has a non-
"inline-translated" element (e.g., a link) amongst its text content.
E.g. This DOM structure:
```
<span class="o_text_highlight o_text_highlight_wavy o_translate_inline">
Go to the <a href="/contactus">Contact Us</a> page
</span>
```
Which caused the translation `<span/>` to be set inside the highlight
structure [A].
Now, as explained in the steps above, there are some cases like with
this DOM:
```
<span class="o_text_highlight o_text_highlight_wavy o_translate_inline">
<a href="/contactus">Contact Us</a>
</span>
```
That will make the translation code check the inner non-"inline
translated" children even within a `o_translate_inline` parent (see:
`translate_xml_node()` > `hastext()` | `process()`), leading to the
same issue as [A].
The goal of this commit is to prevent any similar situation causing the
translation spans to be added inside elements forced to be translated
as a whole, by automatically considering all elements inside a
`o_translate_inline` parent as inline translated too.
This commit also adds a test for the explained behavior.
[1]: https://github.com/odoo/odoo/commit/e9659e55356e5e4de63f2324eb88a7b6f07cd835
opw-4243639
linked to: opw-3980975
linked to: opw-4089482
linked to: opw-4061566This update corrects a visual glitch in the HTML editor for Firefox, preventing the creation of duplicate buttons and links when adding text. The fix resets the browser's internal state, ensuring proper display and functionality after editing links and text within the HTML editor.
Original PR description
In some situations Firefox behaves strangely when adding a character add the end of a button, by duplicating the button element without children and inserting the text between both buttons. It seems Firefox maintains an internal selection state that is corrupted after some operations. This commit resets the collapsed selection inside links in order to reset this internal state in Firefox. Steps to reproduce: - Insert a link - Put some text after the link - Delete the first character from the text - Keep deleting until the last character from the button is deleted - Type a character => The button was duplicated and the text was inserted between both buttons. - Note that if you undo/redo, then typing a character did work fine task-5033890
This update fixes an issue where the table editor loses focus after deleting rows or columns, disrupting the editing workflow. Now, the editor automatically refocuses, ensuring Undo functionality works correctly and improving the overall user experience when managing tables. This prevents confusion and frustration for users.
Original PR description
**Current behavior before PR:** When a user deletes a row or column from table menu, the editor loses focus. As a result, actions like Undo do not behave as expected and require multiple attempts to restore the original table state. This breaks the editing flow, causes confusion when performing table-related actions. **Desired behavior after PR:** This PR ensures that editable is focused after deleting row or column from table menu. This commit also makes sure that selection is set properly and hint is visible on empty cell after deleting the column. task-5725593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a minor issue that prevented the application from functioning correctly when using the Ukrainian language. The fix addresses a problem with how the system retrieves language patterns, ensuring a smoother user experience for Ukrainian-speaking users. This change improves overall application stability and reliability.
Original PR description
**Steps to Reproduce:** 1. Install `stock_fleet` module (with demo data). 2. Set the **Ukrainian** language for the user. 3. Open Fleet > Vehicle > Click Category Error: `KeyError: '2'` **Cause:** Babel's CLDR list patterns for some locales (e.g., Ukrainian 'unit-short') do not include the two-item pattern key, so when babel's `format_list` attempts to access patterns, it will raise an error. **Fix:** This commit wraps the call in a try/except that handles KeyError and retries formatting with the 'standard' style to avoid the crash.
This update fixes an issue where Italian tax information (like VAT number) wasn't being properly carried over when creating a company record from an Italian ecommerce order. This ensures accurate reporting and compliance with Italian tax regulations. The change ensures all required Italian tax fields are populated during company creation.
Original PR description
**STEP TO REPRODUCE** 1. Create a ecommerce order on a shop page of a italian company. 2. Goes to the checkout page, enter info (company_name, l10n_it_codice_fiscale, l10n_it_pa_index). 3. On the contact created, click on create company. 4. Notice l10n_it fields are not propagated to the company. opw-5477372 Forward-Port-Of: odoo/odoo#246785
This update corrects a bug in how loyalty rewards are calculated when products are purchased in non-unit UOMs (like dozens). Previously, rewards weren't applied correctly, requiring a large quantity to trigger the discount. This fix ensures that rewards are accurately applied based on the actual quantity purchased, regardless of the unit of measure.
Original PR description
### Issue: Due to this issue, applying a different uom than unit one, will not apply the reward regarding to quantities. #### Steps to reproduce: 1- Create a program: buy 12 get 6 free. 2- Create a SO, add a dozen of product to SOL. 3- Click on reward. Expect: 6 free unit is added. Current outcome: Nothing is added. Unless you add 12 dozens which is going to add 6 units. ### Cause: In checking rules, `product_uom_qty` is directly used without conversion to quantity. Note: `test_different_uom_to_hours_on_sale_order_confirmation` is failing due to this fix, because the uom_id unit/dozens and hours/days are not compatible. As this is not possible in UI, IMO we can delete the breaking SOL in that test. opw-5913638
This update fixes a bug where customers could still redeem expired ewallet points. The change prevents users from claiming points after their expiration date, ensuring accurate point balances and preventing potential revenue loss. This improves the customer experience and maintains data integrity.
Original PR description
### Issue: Due to this issue, ewallet points are claimable after expiry. #### Steps to reproduce: 1- Create a ewallet program, and generate an ewallet for a partner. 2- Set the expiration date in the past. 3- Create a SO with the same partner. 4- Click on reward. Expected: The ewallet shouldn't be claimable. Current outcome: The ewallet is claimable. opw-5476686
This update fixes an issue where the duration of quick-created calendar events wasn't accurately reflected after manual adjustments. The change ensures that the displayed duration always matches the intended event length, improving event management accuracy. This aligns with recent updates in Odoo 19.0.
Original PR description
Currently, an incorrect duration is displayed when the start or end time is `manually changed` during event creation. **Steps to reproduce:** - Install the `Calendar` module and open the app. - Drag…
Currently, an incorrect duration is displayed when the start or end time is `manually changed` during event creation. **Steps to reproduce:** - Install the `Calendar` module and open the app. - Drag on the calendar to create a `2-hour` time slot (quick-create popup opens). - Manually adjust the start or end time to make the event `3 hours` long. - Click `Save & Close`. - Click on the event: it correctly displays (3 hours). - Click `Edit` and observe the `Duration` value. **Observation:** The duration field shows 2 hours instead of 3 hours. **Root cause:** - The `duration` field is not available (and therefore not stored) in the `quick-create view` at [1]. - When the `stop` time is set manually, the `duration` is computed at [2]. - When the `start` time is changed, the `stop` time is computed based on the previously computed `duration` at [3]. **Fix:** This commit adds the `duration` field to the `quick-create` view as `invisible` (preventing it from being recomputed on each onchange) and `force_save`. This aligns the behavior with `19.0` by preserving the last computed duration in the front-end model, as implemented in PR [4]. [1]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/views/calendar_views.xml#L294-L339 [2]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/models/calendar_event.py#L353-L356 [3]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/models/calendar_event.py#L358-L374 [4]: https://github.com/odoo/odoo/pull/226909 opw-5867946 Forward-Port-Of: odoo/odoo#247193
This update fixes a visual issue where date picker arrows were incorrectly oriented when the website was displayed in RTL (Right-to-Left) languages like Arabic. The fix ensures that date pickers function correctly for all users, regardless of their language settings, improving the overall user experience.
Original PR description
### Steps to reproduce: - Download Rental and eCommerce apps. - Install an RTL language (e.g., Arabic) on the website. - Create a rental and go to website. - Try to pick a date for the rental. ### Issue: When the website is viewed in an RTL language, the navigation arrows of the date picker are displayed in the wrong direction. This happens because the date picker is not inside `o_rtl` component, but inside `o-main-components-container` component. So, when `o_rtl` is called in css (for example): https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/web/static/lib/odoo_ui_icons/style.css#L67-L76 Since the arrows are not inside `o_rtl`, the transformation doesn't apply to them. ### Solution: The `o_rtl` class has been appended to `o-main-components-container` class in case of a RTL language, so that had the css file contain rules for `o_rtl`, they would be applied automatically. opw-5498615
This update fixes a crash that occurred when creating vendor bills with multiple purchase orders linked through the autocomplete field. The issue stemmed from an error in how Odoo handled record insertion, leading to duplicate key errors. By limiting the number of linked purchase orders, this fix ensures stable bill creation.
Original PR description
Steps to reproduce ================== - Edit the Vendor Bill form view to set a limit of 2 on the invoice_line_ids field. - Create 2 purchase orders with the same vendor and 4 products - Create a vendor bill - Set the same vendor - Using the autocomplete field, select the first purchase order - Save the form - Select the other purchase order in the autocomplete field - Delete the record before the last one => Got duplicate key in t-foreach: datapoint_12 Cause of the issue ================== Before inserting the last 4 lines: `this._currentIds = [1, 2, 3, 4]` After the second insert, we have `this._currentIds = [1, 2, virtual_1, 3, virtual 2, virtual_3, virtual_4, 4]` Only the first record is inserted at the correct place, following ones are off by one. opw-5264594
This update resolves a bug where the total time displayed in the Timesheet list view was incorrectly formatted as a regular number instead of a time. The fix ensures the total is always displayed in the correct time format, even after refreshing the page. This improves the accuracy and usability of the Timesheet reporting feature.
Original PR description
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget for the `unit_amount` field. While the row entries were formatted correctly since the widget is added to the fields registry in `timesheet_uom_timer.js`, the aggregate (total sum) is not formatted in the same way because the formatters registry is missing that particular widget. Switching to the grid view and going back to the list view would solve the formatting. That is because the `timesheet_uom_timer` widget is added to the formatters registry when loading the grid view (in `timesheet_grid_uom_service.js`). We ensure the formatter is registered globally by patching the `timesheetGridUOMService` outside the grid view context, ensuring consistent aggregate formatting in list view, even after a page refresh. task-5907954
This update resolves a minor issue related to the scale certificate checksum. It synchronizes the checksum value with a recent fix implemented in the main Odoo project, ensuring consistent and accurate certificate validation. This change improves the reliability of the l10n_eu_iot_scale_cert module.
Original PR description
This commit simply updates the expected scale checksum after the fix in the community PR odoo/odoo#248413.
This update fixes an issue where invoices sent to DIAN or Carvajal would incorrectly display a warning if the invoice date was within a specific range. The change adjusts the allowed date range to align with Colombian regulations, ensuring invoices are processed correctly and avoiding unnecessary errors.
Original PR description
Currently, an `incorrect warning` message is shown when sending an invoice to `DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this date should be considered valid.…
Currently, an `incorrect warning` message is shown when sending an invoice to `DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this date should be considered valid. **Steps to reproduce:** - Install the `l10n_co_dian` module and switch to the `CO company`. - Go to `Invoicing` and create a new invoice with `taxes`. - Set the `Invoice Date` to 6 days before today. - Click `Confirm` > `Send`, ensure `DIAN` is selected, and `send` the invoice. - Observe the warning message. **Observation:** `The issue date can not be older than 5 days or more than 5 days in the future.` **Root cause:** At [1] and [2], the allowed invoice date range is incorrectly computed, using `5 days in the past` and `10 days in the future`. This does not match the Colombian regulations and triggers incorrect validation errors for valid invoice dates. These checks are intentionally implemented in both modules because they apply at different stages and for different providers: 1) `l10n_co_dian` When `DIAN: Free service` is selected as the `Electronic Invoicing Provider` from the `Invoicing Settings`, the date constraint is evaluated at `send time`. After the invoice is created, the validation is performed when the user sends the invoice to `DIAN`, and a blocking error is raised as a `UserError` if the invoice date is outside the allowed range. 2) `l10n_co_edi` When `Carvajal` is selected as the `Electronic Invoicing Provider`, the same rule is checked `at the confirmation time` of the draft invoice. In this case, the validation results in a `chatter message`, not a blocking send-time error. **Fix:** This commit updates the date constraint logic to allow invoices dated up to `6 days before and 6 days after` the current date, in accordance with the DIAN specification described in Anexo Técnico – Documento Soporte No Obligados, page 59, at [3]. <img width="1089" height="120" alt="DIAN" src="https://github.com/user-attachments/assets/408c5ccc-5fed-4585-a81e-dce4ccb98b40" /> [1]: https://github.com/odoo/enterprise/blob/2217827c0989fc5fc8d52a6a9b6f6c6d00b9773f/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L672-L679 [2]: https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/l10n_co_edi/models/account_edi_format.py#L574-L603 [3]: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Documento-Soporte-No-Obligados.pdf opw-5482555
This update fixes an issue where the Accounts Coverage Report incorrectly flagged deprecated accounts as missing. The change removes a filter that excluded inactive accounts, ensuring the report accurately reflects the company's financial data. This improves the report's reliability and provides a more complete picture of account coverage.
Original PR description
Purpose: Accounts Coverage Report considers only active accounts and deprecated accounts are excluded(which should be included).
Steps to reproduce:-
- Switch to company with Belgian COA.
- Open form view of P&L report and click on Accounts Coverage Report.
- Coverage report raises error message that account 667 is reported but does not exist in COA.
- Create an expense account with code 667000 arbitrarily.
- Coverage report does not raises above error.
- Now deprecate 667000 account.
- Coverage report again raises error that account 667 is reported but does not exist in COA.
Solution: remove `('deprecated', '=', False)` from domain.
task- 5906024
Forward-Port-Of: odoo/enterprise#107183
Forward-Port-Of: odoo/enterprise#107085This update adjusts the calculation of sickness relapse periods for Belgian payroll. Starting January 1, 2026, the allowed period between sick leaves to be considered a relapse has increased from 14 to 56 days. This change aligns with updated Belgian tax regulations regarding sick leave recovery periods.
Original PR description
**Spec :-** Since 01/01/2026, the period between two sick time off to consider it as a relapse has been increased from 14 days to 56 days. **Implementation :-** . Update sickness relapse period from 14 to 56 days if the leave starts from 2026 . Add corresponding tests task-5476174
This update fixes a discrepancy in the calculation of car tax (ATN) for employees in Belgium. The changes incorporate the latest tax regulations up to 2026, ensuring accurate payroll processing and compliance with Belgian tax laws. This impacts employees and their associated payroll data.
Original PR description
TaskID: 5932573
This update fixes a reporting issue where the inf-a and inf-b reports weren't correctly identifying businesses without VAT numbers. The changes now include these businesses in the reports and standardize warning messages, ensuring more accurate reporting for tax compliance. This improves the reliability of key financial data.
Original PR description
Both inf-a and inf-b reports should include partners with no vat number. Also updated partner warning on reports to harmonize with main query itself. Now warning is shown if: - no country and no VAT - no country and VAT not starting with EE - no country and VAT is "/"
This update resolves an issue where asset depreciation schedules incorrectly showed assets after they had been disposed of. The fix ensures that disposed assets are no longer included in reporting periods, aligning depreciation schedules with actual asset status. This improves the accuracy of financial reporting.
Original PR description
**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Audit Trail" - Go to "Accounting / Accounting / Management / Assets" - Create an asset: * Original Value: [any] *…
**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Audit Trail" - Go to "Accounting / Accounting / Management / Assets" - Create an asset: * Original Value: [any] * Acquisition Date: [in the past] (e.g. 01/01/2025) * Duration: [at least until today] (e.g. 36 Months) * Depreciation Account: [any] * Expense Account: [any] - Confirm the asset - Modify Depreciation: * Action: Dispose * Date: [in the past] (e.g. 30/10/2025) * Loss Account: [any] - Dispose - Go to "Accounting / Reporting / Management / Depreciation Schedule" - Filter on a period after the disposal date **Issue:** The asset appears in the selected period even if it has already been disposed. **Cause:** There are posted depreciation moves that have a date after the disposal date. These moves should be deleted but the Audit Trail feature prevents it. These moves are cancelled instead. However, the disposal date computed on the asset is taking the max date from all the depreciation moves. Even the cancelled ones ; leading to a disposal date different than the one entered. opw-5225749 Forward-Port-Of: odoo/enterprise#107028
This update fixes an issue preventing correct import of Zengin accounting files. The validation process now allows a wider range of characters, including standard hyphens and alphanumeric text, aligning with the Zengin specification. This ensures all valid Zengin files can be imported correctly.
Original PR description
Before this commit, the Zengin file import validation was permitting only digits, spaces, and half-width Katakana characters. This limitation caused valid files to fail validation if they contained standard ASCII characters, such as the standard hyphen (which differs from the Katakana prolonged sound mark) or alphanumeric text. This commit updates the validation regex to support the full range of characters allowed by the Zengin specification. The allowed character set has been expanded to include: - Uppercase alphanumeric characters (A-Z, 0-9) - Standard symbols (e.g., -, ., /, (, ), etc.) Ref: https://bqa.smbc.co.jp/faq/show/2473?site_domain=web21lite task-5928087 Forward-Port-Of: odoo/enterprise#107007
This update fixes an error where the month displayed on global invoices linked to POS orders was incorrectly reflecting the invoice creation date instead of the order date. This ensures accurate reporting and compliance with Mexican tax regulations. The fix corrects the 'Meses' attribute in the generated XML.
Original PR description
**PROBLEM** In accounting, if you create a global invoice with an invoice, the attribute `Meses` will be the month of the invoice date. In POS, if you do the same with an order, the attribute `Meses` will be equal to the month the day we create the global invoice, instead of the month of the order date. This is wrong. **STEP TO REPRODUCE** 1. Have an order from the month before (not sure how to do this on a runbot). 2. Create a global invoice. 3. Check the generated xml, and notice the month is wrong. opw-5381607