Wednesday, April 24, 2024
26 changes
1 change
Resolved issues and error corrections
Stock operation types must now have default source and destination locations set when configured. This prevents inventory moves from being created without a valid destination, reducing errors in warehouse processing after recent routing changes.
Original PR description
Since the pull&push refactor, the `location_dest_id` of a stock.move is now computed, based on its picking or picking type. It raises an issue, as a picking type can be created without a `default_location_dest_id`. This implies that a move can be created without any destination (no picking yet and picking type has no default dest), which makes no sense. Since we're in stable version, we can only enforce it on the client-side, a real requirement will be set in master. As we enforce the `default_location_dest_id`, we also enforce it for `default_location_src_id` for consistency's sake, even though it is far less critical. Doing so also means providing a compute that will give a default source/destination location regardless of the picking.type's `code`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
24 changes
Resolved issues and error corrections
This update adds support for the asbestos/work accident contribution (amiante) to the Belgian payroll DmfA reporting system. Belgian employers are now required to report this special contribution to social security authorities, and this fix ensures the payroll system correctly calculates and includes this contribution in the DmfA declarations.
Original PR description
https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/instructions/special_contributions/other_specialcontributions/asbestosfunds.html
This update aligns the Belgian employment bonus calculations with the new 2024 government system that took effect April 1st. The changes ensure employees receive the correct bonus amounts under the updated rules, which include revised thresholds and calculation methods as mandated by Belgian social security authorities.
Original PR description
Sources: https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/intermediates#bonus-a-l-emploi-plafonds-apres-l-augmentation-du-rmmmg-et-la-scission-du-calcul-29-03-2024 https://www.ucm.be/actualites/le-bonus-lemploi-renforce-au-1er-avril-2024#:~:text=Qu'est-ce%20que%20le,salaire%20net%20effectif%20est%20augment%C3%A9
This fix corrects the module assignment for maintenance worksheets, which was preventing proper cleanup when uninstalling the maintenance module. Previously, database entries would remain after uninstalling because the system couldn't identify all related records to remove. This ensures a clean uninstall process.
Original PR description
Since the wrong module set on the maintenance worksheets, this would lead to issues when trying to uninstall the maintenance module, as it wouldn't find every models to uninstall. This ended up leaving some entries in the database after the module was removed. runbot-57422
Fixed an issue where the timer was incorrectly appearing in the All Timesheets kanban view. The timer should only be visible in the My Timesheets view. This fix uses a context flag to properly hide the timer header in the shared kanban view while keeping it available where it's needed.
Original PR description
Steps to Reproduce: - Install Timesheets app - Navigate to All timesheets from the header menu - Click on kanban view Issue: - Timer is present in the All timesheets Kanban view Causes: - Timer is present in the All timesheet kanban view because this view is inherited in my time sheets. Solution: - Using the context that is only used in MyTimeSheet Action window to hide the timer header (my_timesheet_display_timer) task-3741260 Forward-Port-Of: odoo/enterprise#56581
This fix resolves an issue where Sendcloud shipping with pick-up locations was failing due to incomplete delivery addresses. The house number was not being included when creating customer addresses, causing Sendcloud to reject the shipment. The update now ensures the complete address, including house number, is properly captured and sent to Sendcloud.
Original PR description
Steps to reproduce: 1. Configure Sendcloud shipping with pick-up location 2. Go to website, use the shipping method and select a pick-up location 3. Go to the backend, confirm the sale order and validate the delivery 4. Get Error from Sendcloud that the `house_number` is required If we check the delivery address, we see that the house number is not taken into account when creating a new partner, and the address is incomplete. This commit adds the house number to the `street` field of the address to have a complete address. opw-3864382
This update fixes visual issues with form inputs across the website and web modules to make them clearer and more consistent. Disabled input fields are now more visually distinct, dropdown carets are more visible on dark backgrounds, and checkboxes/radio buttons maintain readability with custom theme colors. These changes improve the user experience when interacting with forms and product configurations.
Original PR description
### Adjust disabled input colors (*1) 1. Maintain border consistency of frontend inputs : Prior to this PR, `form-select` borders overlapped the background color, which is not the case with…
### Adjust disabled input colors (*1) 1. Maintain border consistency of frontend inputs : Prior to this PR, `form-select` borders overlapped the background color, which is not the case with `form-control`. This is because `form-control` uses the `background-clip` property. As we're using a semi-transparent border on frontend inputs, this creates a color issue: when a `form-select` input is disabled, the border color is darker than that of the `form-control`. This PR adapts the `background-clip` on `form-select` input to maintain color consistency between inputs. 2. Make disabled inputs more recognizable : Prior to this PR, disabled inputs were not sufficiently distinct from regular inputs, especially `website_sale` inputs which had a gray background. **Steps to reproduce:** - Make sure your instance has`website_sale_renting` installed. - Go to the Shop page. - Look for a product with a rental period (eg. Printer). - Click on Add to cart, this will disable the rental period input. - -> The gray search bar and the disabled input have almost the same style This PR adapts the style of disabled inputs in the frontend to make them more recognizable. --- ### Adjust dropdown caret color (*2) Prior to this PR, dropdown inputs had a color issue in frontend: the caret color of `form-select` was dark regardless of the input's background and didn't provide enough contrast when we defined a dark background on the page. **Steps to reproduce:** - Go to the Contact page. - Click on Edit. - Click on Theme tab. - Replace the fourth color with a dark one (ex. black). - Click on the form in the page. - Add a field. - Select the new field and choose the "Selection" type. - Click on Save. - -> The dropdown caret is not enough visible. --- ### Adjust `form-check-input` colors (*3) This PR adjusts the caret color to make sure that this will be always visible. Prior to this PR, checkboxes, radios and switch inputs had a color issue in frontend: as the inner element (eg. check mark) was always white if the user changed the primary color to a bright one, the inputs were no longer readable. **Steps to reproduce:** - Go to the Contact page. - Click on Edit. - Click on Theme tab. - Replace the primary color with a bright one (ex. light gray). - Click on the form in the page. - Add a field. - Select the new field and choose the "Radio Buttons" or " Checkbox" type. - Click on Save. - Check the checkbox or the radio button. - -> The check mark or the dot is not visible enough. This PR adjusts the colors to ensure that these inputs will always be visible. --- ### Adjust `form-range` track color (*4) Prior to this PR, the `form-range` track color used the light color. This created a color inconsistency with the rest of the UI when we changed the third color. **Steps to reproduce:** - Go to the Shop page. - Click on Edit. - Click on the page and make sure "Price Filter" is active in the Web Editor. - Go to Theme tab. - Change color-3 (light) to another one (eg. red). This PR adjusts the color to maintain consistency with the rest of UI elements --- ### Adjust custom dropdown caret (*5) Prior to this PR, the custom dropdown caret in the `website_sale` sidebar didn't handle the "multiple" attribute, unlike the default dropdown. If we decided to add a "multiple" attribute to this element, the caret remained displayed, which created a design issue. This PR adapts the caret of this dropdown so that it works correctly when this attribute is defined. --- task-3702675 --- | (*1) | Before | After | | -- | - | - | | Portal |  |  | | Website (light bg) |  |  | | Website (dark bg) |  |  | | (*2) | Before | After | | -- | - | - | | Adjust dropdown caret color |  |  | | (*3) | Before | After | | -- | - | - | | Adjust `form-check-input` colors |  |  | | (*4) | Before | After | | -- | - | - | | Adjust `form-range` track color |  |  | | (*5) | Before | After | | -- | - | - | | Adjust custom dropdown caret |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where saving document layouts with tabs in the footer or HTML fields would fail when switching between different browsers. The problem occurred because tab formatting wasn't being properly recognized during the save process, causing errors. The fix ensures that formatting changes are detected correctly from the start, preventing save failures when users work with the same document across multiple browsers.
Original PR description
Issue: ====== If you have some tabs in a html_field, opening with a different browser may cause an issue when saving the document layout. Steps to reproduce the issue: ============================= -…
Issue: ====== If you have some tabs in a html_field, opening with a different browser may cause an issue when saving the document layout. Steps to reproduce the issue: ============================= - Open with firefox - Go to settings , document layout - Added some `tab` in the footer or any html field - save - Open with chrome - Go to settings , document layout - click save without doing anything - error Origin of the issue: ==================== When calling sanitize in the constructor, the tabs size doesn't change because we didn't add the class `odoo-editor-editable` which doesn't make the `editable` dirty since no changes has been made. When calling save, `cleanForSave` will be called with a clone of the `editable` so in sanitize it won't matter since the element is not connected to the dom so again no changes and the edtior still no dirty, after that , `onWillUpdateProps` of `Wysiwyg` will be called and we will set the value of the editor by the new value which will call `resetContent` of `odooEditor` and it will sanitize the editable but this time it has the class `odoo-editor-editable` so the finally the sizes of the tabs will be changed and the editable will become dirty. Now `onWillUnmount` in `html_field` will be called and since the field is dirty it will commit changes as a normal save , but a traceback will occur since the component is already destroyed. Solution: ========= Add the class `odoo-edtior-editable` before the call to sanitize to mark the field as dirty from the start and will be updated with the new sizes of tabs on the first commit and not in the commit of `onWillUnmount`. opw-3742423
This fix corrects how project status displays sales order items by filtering out section headers and notes that don't represent actual products or services. Previously, these non-billable line items were incorrectly appearing in the project overview, cluttering the profitability and time investment analysis. The fix ensures only relevant sales items are shown to help managers better understand project performance.
Original PR description
## Reported issue ### Steps to reproduce: Be sure that 'industry_fsm' is installed. - Go to Project > Projects and swap to the list view - Create and save a new project with a customer - Access the…
## Reported issue ### Steps to reproduce: Be sure that 'industry_fsm' is installed. - Go to Project > Projects and swap to the list view - Create and save a new project with a customer - Access the related SO via the smart button - Add a service product, a storable product a section and a note - Go back and access the project status with the smart button #### > The SOL generated for the section and the note appear as SO items ### Expected behavior: The purpose of the project status tab is to have an overview at the project to help in the analyse its profitability, the time investment,... as such, these SOL should not be considered as SO items. In addition, these lines lose their entire purpose in the list view used in this overview (they can not be moved and display irrelevant infos). ### Cause of the issue: These lines were not filtered out by the current query. ## Second Issue: ### Steps to reproduce: Install only the "project" and "sale_management" module and reproduce the same flow as above. #### > Only the service product is displayed as a SO items. ### Cause of the issue: Since the onchange method: https://github.com/odoo/odoo/blob/f72968561acec164697a7a9ee0965ec304854dd5/addons/sale_project/models/sale_order.py#L124-L128 is triggered before an analytic account is linked to the project, the sale order created in our flow will not be linked to an `analytic_account_id`. In particular, as this value is null in the DB and is not computed it can not be relied on here: https://github.com/odoo/odoo/blob/7f5f2963966f5a3bcfeb4bede0f9d956fff6e831/addons/sale_project/models/project.py#L341 to define the SQL query fetching our SOL. ##### Note: If the `industry_fsm` module is installed, the second issue do not happen because an analytic account is linked to the project before the trigger of the onchange method. In particular, since the behavior of this flow is different with additional modules installed we added both a test "at install" and a test "post install". opw-3794386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue in Odoo's template engine (QWeb) that was incorrectly closing XML elements with namespaces like <g:link>. The system was treating namespaced elements the same as standard HTML void elements, preventing proper nesting of content. This fix ensures that namespaced elements are handled correctly, allowing developers to use XML namespaces in templates as intended.
Original PR description
Until now, it is impossible to do <g:title>xxx</title> because qweb will autoclose the <g:link> because it checks if link is a void element instead to check g:link. Now we check the el_tag instead of unqualified_tag. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where empty receipts were being printed twice when customers add tips after payment in restaurant POS settings. The problem occurred because the tip receipt template was missing the total amount display, and the system wasn't properly handling cases without a physical printer. This improvement ensures receipts only print when they contain actual data.
Original PR description
### Steps to reproduce:
- Install **POS** app.
- Go to **POS** settings and enable:
- Is a Bar/Restaurant
- Tips > Add tip after payment
- Open a POS session -if first time, add a floor and a table-
- Add a product
- Click on **payment**
- Choose a payment method
- Click on **Close Tab**
- The print popup is shown twice in a row with an empty receipt.
### Investigation:
Investigation:
- Inside the `TipReceipt` template, the `total` is not shown as the class lacks a getter for it https://github.com/odoo/odoo/blob/1d49034782e3ff0e4384bad4e927a895e2a97839/addons/pos_restaurant/static/src/app/tip_receipt/tip_receipt.xml#L13-L16
- Also when there is no printer, we won't fallback to the web printer as it's annoying to the cashier.
opw-3836549This fix resolves an issue where cost of goods sold (COGS) entries were not being created when processing partial downpayments on sales orders with real-time inventory valuation. The system now correctly recognizes when to generate COGS entries even when credit notes with negative quantities are involved, ensuring accurate financial reporting for inventory costs.
Original PR description
Usecase to reproduce: - Product wiht a real time valuation - Product with invoice on delivered quantity - Create a SO for 5 units and 1000$ each - Do a full downpayment of 100% of quotation - Deliver 3 out of 5 units and create a backorder - Create an invoice - Validate the invoice Expected behavior: The cogs entries are there Current behavior: No cogs It only happens with partial downpayment. When the downpayment amount equals the quotation amount. An invoice is created instead of a credit note and the process works correctly. It happens because it creates a credit note with a negative quantity to invoice so the system doesn't understand it has to create the cogs at that point. 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 Forward-Port-Of: odoo/odoo#161098
When downloading multiple invoices as a ZIP file, the Factur-X XML files were being overwritten because they all had the same generic filename. This fix ensures each invoice's XML file has a unique name so all files are properly included in the download. Users can now successfully download complete invoice packages with all corresponding XML documents.
Original PR description
Context: in 17.0 we enabled mass download for invoices. We expect this download to create a zip with all PDF invoices and their related xml files. Steps to reproduce: 1. Install l10n_fr 2. Create two invoices to french partners 3. Send & Print the two invoices and select 'Factur-x" and "Download" 4. A .zip file is generated with two PDF but only **one** XML file "factur-x.xml" Cause: The name of the XML file for the factur-x XML file is not specific to related invoice, it gets overriden each time it is generated. See: https://github.com/odoo/odoo/pull/137382 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 a bug where single-value graphs were not displaying correctly in cumulated graph views. The issue was caused by a technical ordering problem that resulted in invalid calculations. Users will now see all their graph data properly displayed in cumulated views.
Original PR description
Single value graph were not shown in cumulated graph. This is due to unshift happening before the accumulator, leading to `undefined + X = NaN` for the value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162247
This fix resolves an issue where event privacy settings marked as 'Available' in Odoo were not being properly synchronized to Google Calendar. Users will now see their privacy preferences correctly reflected across both Odoo and Google Calendar, ensuring consistent calendar management across platforms.
Original PR description
### Version - 16.0 ### Steps to reproduce - Create a event from odoo calendar with privacy 'Available' - Open google calendar and open that event ### Issue - When the user sets privacy as 'Available' in Odoo, it is not properly synchronized in Google Calendar. ### Solution - Syncing privacy value changes between odoo and Google Calendar will be correct after this commit by passing the `transparency` value. task-3667696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157545
This fix resolves an issue where UBL invoice exports were incorrectly generating validation errors when processing invoices for customers with separate invoicing addresses. The fix adjusts how the system validates customer information during the export process, ensuring that properly configured customers no longer trigger false error messages.
Original PR description
Problem --------- Because of this PR: 155896, the customer default value for the UBL export values has been modified from commercial partner to partner. However, in 16.0+, some constraints have been added to verify that some fields were properly set up before generating the XML. Those restrictions clash with the said changes. Indeed: 1 - Create NO company 2 - Set up UBL on invoice journal 3 - Create a new NO customer and set up UBL in the same way 4 - Create an invoicing address for that customer 5 - Create an invoice for with the customer set as the invoice address set up in step 3. 6 - Send & Print with UBL selected >> An error is added to the export errors while it should not. Solution --------- Use the commercial partner when checking constrains of all fields other than addresses. OPW-3848367 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162366 Forward-Port-Of: odoo/odoo#160523
This update resolves a visual display problem in the Activity view where the activity counter badge was overlapping with the activity deadline information. The fix improves the layout by adjusting the styling of activity cells, making it easier for users to see both the activity count and deadline clearly when multiple activities are scheduled for the same day.
Original PR description
**Steps to reproduce:** - Go to activity view. (Ensure that it has at least 10-12 activity types) - Schedule multiple activities for the same day. - Activity count badge overlaps activity deadline! **Before this PR:** Activity count badge overlaps the activity deadline in an activity cell. **After this PR:** The issue has been resolved by tweaking the CSS of Activity Cell. Task-[3818264](https://www.odoo.com/web#id=3818264&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#162573 Forward-Port-Of: odoo/odoo#158512
This fix corrects an issue where expenses created via email alias would be assigned to the wrong employee when a user has multiple employee profiles. Previously, the system would select the first employee record instead of the correct one based on the user's default company setting. Now expenses are properly assigned to the right employee, preventing errors and ensuring accurate expense tracking.
Original PR description
[FIX] hr_expense: select the right employee for an expense created with alias Current behavior: When trying to create an expense using alias, if there's several `hr.employee` linked to a user, it select the first one instead of this with the right company Steps to reproduce the error : - Create different employee's profiles for a same user - Put the default one on the user's profile (don't put the first that you created because it will select the first for the expense) - Try to send an email to the expense's alias and check at the logs After this commit: The right employee (this one in the default company) will be selected and no error will be triggered opw-3754015 Forward-Port-Of: odoo/odoo#161853
This fix prevents the system from overriding custom reconciliation settings that customers have configured on their accounts during database upgrades. Previously, the upgrade process would reset these settings and cause errors when accounts had pending partial reconciliations, disrupting the upgrade process. Now, custom settings are preserved, ensuring smooth upgrades without data conflicts.
Original PR description
In some databases, customers have changed the `reconcile` value of an account from its standard `False` value to `True`. This action causes related journal items, which are partially reconciled, to raise the following constraint error. during the upgrade process: ``` You cannot switch an account to prevent the reconciliation if some partial reconciliations are still pending ``` so we delete changes in the `reconcile` values from the reload to avoid overriding user customer setting & triggering the constraint error. 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 Forward-Port-Of: odoo/odoo#160086
This fix corrects a bug in the delivery/shipping module where free shipping thresholds set for fixed-price providers were incorrectly still being applied when users switched to rule-based pricing. The fix ensures that rule-based shipping methods ignore these thresholds while keeping the data intact in the system.
Original PR description
Problem: when configuring a provider (from the form view) in shipping methods, after: * setting the provider to "Fixed Price" * setting the free_over / amount field * changing the provider to "Based on Rules" the free_over / amount still applies even though the field becomes hidden. Desired behavior after: When the provider is "Based on Rules", ignore the `free_over` / `amount` if it is set (but don't unset it, still hide it in the view). opw-3852858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160975
This fix prevents the system from crashing when users upload image files (like WEBP or SVG) with incorrect file extensions (JPG or PNG). The system now properly detects mismatched file types and handles them gracefully with a user-friendly error message instead of a technical failure.
Original PR description
Uploading a WEBP or SVG file disguised with a proper file extension (JPG, PNG) will cause a traceback because img.image is not populated when there is an empty source, SVG, or WEBP file uploaded as…
Uploading a WEBP or SVG file disguised with a proper file extension (JPG, PNG) will cause a traceback because img.image is not populated when there is an empty source, SVG, or WEBP file uploaded as this code should not be reached with these file types. The reason this occurs is because we check for the file extension when deciding to post process an image, but when we get to initializing the ImageProcess object, we then check the actual file structure to verify the type of file. This is a workaround for the time being, but should not be a final solution in future versions. Adding a null check on img.image in the _postprocess_contents method in order to avoid attempting to access the size of this image when it is null. Raises a user error in order to trigger the catch and exit the code while logging the error and 'Post processing ignored:'. opw-3672250 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156209
This fix addresses an oversight in the zeep client tool that was preventing Spanish EDI (Electronic Data Interchange) services from properly configuring test environments. The Spanish invoicing module requires access to binding options when connecting to the SII service, which was missing. This fix restores that functionality so companies can correctly switch between production and test environments for their electronic invoicing.
Original PR description
`l10n_es_edi_sii` requires `Client.bind` as well as `_binding_options` in the service returned by this `bind` call.
```py
serv = client.bind('siiService', service_name)
if company.l10n_es_edi_test_env and connection_vals.get('test_url'):
serv._binding_options['address'] = connection_vals['test_url']
```
Can be tested with a external l1On unit test,
tested only in nightly builds,
not by regular runbot builds / mergebot.
`--test-tags=external_l10n:TestEdiWebServices`
opw-3888257
opw-3888559
opw-3888155
opw-3890269
opw-3889683
Manual forward port of odoo/odoo#163119 to expedite the merge as quick as possible.This fix corrects a bug where unbuild orders were creating incorrect inventory movements when the actual quantity produced in a manufacturing order differed from the planned quantity. Specifically, when more items were produced than expected, an extra unintended inventory movement was being generated. This ensures accurate inventory tracking when reversing manufacturing orders.
Original PR description
When the Manufacturing Order 'qty_produced' is different from the 'product_qty' (we produced more or less than expected), then unbuild order had the wrong quantity for the finished product, and if 'mo_id.qty_produced > mo_id.product_qty', then an extra confirmed move was generated upon the validation of the unbuild order. --- FYI: note that in `mrp_unbuild.py` at line 245, there is almost the same function, and the factor uses `qty_produced` instead of `product_qty`, so this PR mostly synchronize the logic. --- OPW-3860612
When archiving a company branch, all of its sub-branches are now automatically archived as well. This prevents configuration issues where inactive parent branches leave orphaned child branches, which was causing features like the tax report closing entry button to become disabled unexpectedly.
Original PR description
Original issue: 1) Create a company "main", with 2 branches: "A" and "B" 2) Create a sub-branch for "A": "A1" 3) Archive company A 4) In the company selector, make "main" the active company. It will…
Original issue:
1) Create a company "main", with 2 branches: "A" and "B" 2) Create a sub-branch for "A": "A1"
3) Archive company A
4) In the company selector, make "main" the active company. It will auto-select branch B as well. 5) Open the tax report, and try clicking the "Closing Entry" button ==> The button is disabled ; it shouldn't be.
This happens because Odoo considers the full hierachy of branches to submit together is not selected. The problem originates in the way _get_branches_with_same_vat searches for sub-branches, doing
self.env['res.company'].sudo().search([('id', 'child_of', current.root_id.ids)])
In our example, this search will return main, B and A1. We then compare that with the company selector, which only contains main and B.
This configuration of companies does not make sense functionally speaking, as a branch whose parent is inactive will not be usable anyway. Therefore, we now archive all the sub-branches when archiving a company.
opw-3877368
task-3878070
Forward-Port-Of: odoo/odoo#162638This update upgrades the XRechnung electronic invoice standard from version 2.x to version 3.0.1 in Odoo's accounting module. Previously, invoices generated in XRechnung format would trigger validation warnings when submitted to official German validation services. This fix ensures invoices now comply with the latest standard requirements and pass validation without warnings.
Original PR description
Before this fix, any XRechnung xml will raise a warning when being submitted on https://erechnungsvalidator.service-bw.de/. The warning states: "[BR-DE-21] Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen." This is because the version 3.0.1 has been released. issue-160644 Forward-Port-Of: odoo/odoo#162187