Daily updates from Odoo
Navigate
Branch
Monday, February 28, 2022
18 changes
New functionality added to Odoo
A new Belgian reporting module changes the tax return posting flow so users can configure an XML VAT return export before posting. The system now generates the XML alongside the PDF and attaches both to the tax return entry, supporting Belgian compliance workflows.
Original PR description
This new module replaces the POST button on tax return entries and opens the view_account_financial_report_export wizard first, in order to configure the XML VAT return export file, which is generated along with the PDF file, and attached in the chatter of the entry. This module is intended to be merged into l10n_be_reports in a future version. [OPW-2392054](https://www.odoo.com/web#id=2392054&model=project.task)
A new reminder activity is created when a tax return entry is closed, helping users remember that related attachments still need to be sent to the relevant tax authority. This reduces the risk of missing an administrative follow-up after preparing tax reports.
Original PR description
When closing a tax return account move, add a new next activity on it, because its attachments still have to be sent to the administration of the country. [OPW-2392054](https://www.odoo.com/web#id=2392054&model=project.task)
Enhancements to existing features
Payroll batch calculations, salary simulations, and related HR screens have been optimized to avoid unnecessary background work and record creation. This should make salary and payslip processes faster and smoother for HR teams, especially when handling larger volumes.
Project and field service forms now use clearer action labels and include an Unschedule option to reset planned start and end dates. The unnecessary Remove button was removed, making scheduling workflows easier to understand and reducing accidental actions.
Original PR description
Before these changes : - In the project form, we have 'save & close', 'save & add' and 'remove' buttons, a button to reset planning dates was needed and remove button was useless. - Some wordings didn't have a significant meaning. These changes : - Adds new button 'unschedule' to reset start and end date - Deletes 'remove' button - Changes 'save & close' and 'save & add' buttons with 'save' as the JS framework doesn't allow us to keep these two buttons and add a custom button like unschedule (it was validated by the PO) - Improves some wordings according to what was mentioned in the task. Community Related PR : https://github.com/odoo/odoo/pull/82135 task-2724965
This update aligns customer portal pages with shared portal handling so support and subscription pages receive the right page data automatically. It reduces duplicated template setup and helps keep portal pages consistent and easier to maintain.
Original PR description
* adapt to the fact that _get_page_view_values now specifies the object in the rendering values * make sure the method is used when useful * remove useless respecified parameters in qweb COM PR: https://github.com/odoo/odoo/pull/84644
This update streamlines the sales reporting setup by removing redundant logic and aligning it with the latest sales reporting structure. It should make reporting easier to maintain while keeping the visible business reports consistent.
Original PR description
following changes in community * remove unused join on crm teams defined in website_sale_dashboard * Remove the redefinition of invoice_status in website_sale_dashboard and make it depend on sale_enterprise * adapt to the new API & hooks in the base sale module Community PR: https://github.com/odoo/odoo/pull/85125
Payroll now includes ready-to-use salary structures even when demo data is not installed, making initial setup easier. A new guided tour introduces users to the core payroll workflow so teams can learn the basics faster.
Original PR description
Have some salary structure ready without demo data. Add a JS tour to show the basic functionality of Payroll. TaskID: 2661217
Code cleanup and technical improvements
Point of Sale code and labels were renamed to more clearly distinguish business partner records from real-life customers. This reduces ambiguity for future maintenance without changing how users interact with the system.
Original PR description
- Renaming of the substring `client` and `customer` to `partner` (css included) when it was referencing to the actual `res.partner` object. This way, developers will always know that the object used in the UI is coming from `res.partner`. - Renaming of the substring `client` to `customer`(css included) when it was referencing to a real life person. This avoid having ambiguity since the term `client` can refers to multiple things (hardware, browser, person, ...)
Miscellaneous changes
Fixes a possible division by zero error when the hours_per_week is not filled on resource.calendars. TaskId-2764680 Forward-Port-Of: odoo/enterprise#24836 Forward-Port-Of: odoo/enterprise#24780
Original PR description
Fixes a possible division by zero error when the hours_per_week is not filled on resource.calendars. TaskId-2764680 Forward-Port-Of: odoo/enterprise#24836 Forward-Port-Of: odoo/enterprise#24780
Prior to this commit: - When test_timesheet_grid_filter_equal_string was launched a saturday evening after 23:00, the test was failing as it was considering the next week in the call to read_grid, where context_today is used. After this commit: - Thanks to freezegun, we ensure that the test is not running on a saturday 23:00. Forward-Port-Of: odoo/enterprise#24821
Original PR description
Prior to this commit: - When test_timesheet_grid_filter_equal_string was launched a saturday evening after 23:00, the test was failing as it was considering the next week in the call to read_grid, where context_today is used. After this commit: - Thanks to freezegun, we ensure that the test is not running on a saturday 23:00. Forward-Port-Of: odoo/enterprise#24821
When using account groups with hierarchy and subtotals on financial reports, duplicates were created when unfolding children lines. The bug was introduced in this commit: https://github.com/odoo/enterprise/commit/f13ca39ce684e28375c163be2f6812275438e991 opw-2775111 Forward-Port-Of: odoo/enterprise#24781
Original PR description
When using account groups with hierarchy and subtotals on financial reports, duplicates were created when unfolding children lines. The bug was introduced in this commit: https://github.com/odoo/enterprise/commit/f13ca39ce684e28375c163be2f6812275438e991 opw-2775111 Forward-Port-Of: odoo/enterprise#24781
Before this PR, the numbering system used by luxon to parse and format dates was the one set by the current locale. This means that any date sent to and received from the server would also be expected to use the current locale and numbering system. The consequence of this behavior is that any domain generated by arbitrary dates would trigger a server error. This PR forces the numbering system to 'latn' (browser default) for dates used by the server. Community: https://github.com/odoo
Original PR description
Before this PR, the numbering system used by luxon to parse and format dates was the one set by the current locale. This means that any date sent to and received from the server would also be expected to use the current locale and numbering system. The consequence of this behavior is that any domain generated by arbitrary dates would trigger a server error. This PR forces the numbering system to 'latn' (browser default) for dates used by the server. Community: https://github.com/odoo/odoo/pull/85014 Forward-Port-Of: odoo/enterprise#24736 Forward-Port-Of: odoo/enterprise#24589
The patch has been implemented in the odoo base code but the bug has been discovered by using this module. That's why the test has been added in this module. How to reproduce the bug: - Install POS and data_cleaning - Create 2 customers and set loyalty points - Select both customers and merge them - Once the merge is done, the loyalty points have not been summed Bug: When you merge 2 contacts that have both loyalty points, the resulting contact won't have the sum of the 2 sourc
Original PR description
The patch has been implemented in the odoo base code but the bug has been discovered by using this module. That's why the test has been added in this module. How to reproduce the bug: - Install POS and data_cleaning - Create 2 customers and set loyalty points - Select both customers and merge them - Once the merge is done, the loyalty points have not been summed Bug: When you merge 2 contacts that have both loyalty points, the resulting contact won't have the sum of the 2 source contacts. Instead of that, the resulting contact will only have the points of one of of the contact. opw-2686208 Forward-Port-Of: odoo/enterprise#24059
Steps to reproduce the bug: - Connect with a Belgian company - Install delivery_bpost - Create a new SO: - Add a Belgian customer - Add any storable product - Click on “Add shipping” > Select “Bpost 24h” > get rate - Confirm - Go to the linked delivery > Validate - Click on the tracking widget Problem: Bpost cannot find the tracking of the package because the link is incorrect. Solution: Bpost now needs the tracking number and the postal code in the link to displ
Original PR description
Steps to reproduce the bug:
- Connect with a Belgian company
- Install delivery_bpost
- Create a new SO:
- Add a Belgian customer
- Add any storable product
- Click on “Add shipping” > Select “Bpost 24h” > get rate
- Confirm
- Go to the linked delivery > Validate
- Click on the tracking widget
Problem:
Bpost cannot find the tracking of the package because the link is incorrect.
Solution:
Bpost now needs the tracking number and the postal code in the link to display the information.
opw-2762001
https://user-images.githubusercontent.com/78867936/155346015-9c4487bf-5140-4afb-9576-e3c64ca059af.mp4
Forward-Port-Of: odoo/enterprise#24751
Forward-Port-Of: odoo/enterprise#24667Forward-Port-Of: odoo/enterprise#24621
Original PR description
Forward-Port-Of: odoo/enterprise#24621
Forward-Port-Of: odoo/enterprise#24613
Original PR description
Forward-Port-Of: odoo/enterprise#24613
To pass validation by the PAC, the tax amounts reported for each invoice line need to fulfil the following two conditions: (1) The total tax amount must be equal to the sum of the tax amounts reported for each invoice line. (2) The tax amount reported for each line must be equal to (tax rate * base amount), rounded either up or down. In version 15.0, a new tax allocation method was introduced where the tax line's amount is distributed proportionately to the base amount of the i
Original PR description
To pass validation by the PAC, the tax amounts reported for each invoice line need to fulfil the following two conditions: (1) The total tax amount must be equal to the sum of the tax amounts…
To pass validation by the PAC, the tax amounts reported for each
invoice line need to fulfil the following two conditions:
(1) The total tax amount must be equal to the sum of the tax amounts
reported for each invoice line.
(2) The tax amount reported for each line must be equal to
(tax rate * base amount), rounded either up or down.
In version 15.0, a new tax allocation method was introduced where the
tax line's amount is distributed proportionately to the base amount
of the invoice lines to which the tax applies. This works well when
using the 'Round Globally' method, but in the case of 'Round per
Line', this sometimes breaks condition (2), which causes a
validation error with the PAC.
(introduced by commit 433656415a3c5a0720d27ab8c1e15d9154110a86)
Conversely, the old 14.0 tax allocation method worked well when using
the 'Round per Line' method, but in the case of 'Round Globally'
it sometimes broke condition (1).
To fix this, in the sister PR github.com/odoo/odoo/pull/84312
we have created a flag in the `_prepare_edi_tax_details` method
which lets us choose whether to use the new tax allocation method,
or the old 14.0 tax allocation method.
This PR makes `_l10n_mx_edi_get_invoice_cfdi_values` use the new
tax allocation method if 'Round Globally' is set, and the old one
if 'Round per Line' is set.
This PR also adds a test that helps us avoid regressions by testing
that these two conditions are fulfilled even in a difficult scenario
(where rounding errors could potentially affect how the total tax
amount is allocated among invoice lines).
Forward-Port-Of: odoo/enterprise#24656To reproduce: Publish UPS US with the package type UPS Package/customer supplied Try to send the package to a us address Error "Error: Package exceeds the maximum length constraint of 108 inches. Length is the longest side of a package." When dimensions are not provided, the default package is chosen, which is 520x520x520 mm. The user can select between two dimension units (inches or centimeteres) in shippement method. If the user chose inches (same thing for CM), the ups API is called w
Original PR description
To reproduce:
Publish UPS US with the package type UPS Package/customer supplied
Try to send the package to a us address
Error "Error: Package exceeds the maximum length constraint of 108 inches. Length is the longest side of a package."
When dimensions are not provided, the default package is chosen, which is 520x520x520 mm.
The user can select between two dimension units (inches or centimeteres) in shippement method.
If the user chose inches (same thing for CM), the ups API is called with { dimensions : 520x520x520, unit : IN }.
Which exceeds the length limit 108 IN.
To fix that, the package 520x520x520 (MM) has been changed to 52x52x52 (CM).
So that even if the user chose IN as default unit that will not exceed the 108 IN limit
opw-2733844
Forward-Port-Of: odoo/enterprise#23800